An unsolicited "thank you"

gaekwad · Yesterday 09:44:42

I haven’t yet fully formulated the sentiment of what I want to express here, but I want to give thanks to Textpattern CMS. This post will be a little haphazard as I get stuff out, so I thank you in advance for your patience and understanding.

The thanks I wish to pass on to everyone involved in our project is the comparatively lightweight footprint of our CMS. Here’s why…

I am involved in a new-ish project that is taking up a lot of my time, energy and headspace. I am willingly taking on this project, but it’s tough and my fuel tanks are regularly pretty low or empty.

My project is making use of open source / libre software & services where possible, with a view to sustainability and an element of information sharing that will have positive knock-on effects for other projects.

I’m using Textpattern for the main website. I’m using Leantime for project management. I’m using LimeSurvey for questionnaires. I’m using SuiteCRM for customer management. All open source, all permissive licenses, and countless amounts of expertise is baked into each one. I am incredibly grateful that all these projects exist in the open source arena.

Textpattern – when decompressed from its archive and stripped back for non-RPC, non-multisite + English (Great Britain) language pack with Hive admin theme – is ~4.5MB total disk space.

Leantime is ~238MB out of the box. LimeSurvey is ~373MB out of the box. SuiteCRM is ~380MB out of the box. I haven’t done any sort of optimisation on any of these packages because I don’t understand them well enough (yet), but the difference is night and day when it comes to updates.

I’m using low-cost, EU hosting for this project as it’s most cost-effective, and the SFTP connection bandwidth is pretty unforgiving as a result. An update to Leantime / LimeSurvey / SuiteCRM involves uploading hundreds of MB over a series of tubes and involves some thumb twiddling while things happen.

A Textpattern upload takes a minute or two, maximum. Anecdotally, I cannot fully explain how much I really appreciate this.

It would be arguably less effort to add all kinds of extra things to Textpattern…and add extra MB, and increase the audience, and the attack surface, and the complexity, and memory requirements, and other things.

The care and consideration that goes into this project is unlike anything else I’ve encounter in 30+ years online. Admittedly, yes, there are times when I get frustrated and bang my head against the wall…but it’s days like today that I understand why.

So: thank you from me to everyone involved in this project for being pedantic, picky, selective, considerate, annoying, helpful, obsessive, distractible, and – ultimately – awesome.

Bloke · Yesterday 10:49:21

You’re absolutely welcome.

I get what you’re getting at. Sometimes it does feel like being deliberately obstinate to find a more efficient or less memory-intensive or disk space-consuming solution, but to me—as a person who came from an era where you had to squeeze every byte of performance out of 5KB—it’s a big deal to make things zing.

I had this exact, shall we say, argument recently on Stack Overflow. I’m working on a shop plugin in the background. It’s going well. But integrating with payment gateways is proving tough. There’s a great library called OmniPay that has bolt-ons for a couple of hundred gateways and it’d be wonderful. But it’s 8MB. That’s bigger than a stripped-back Txp. Just for one plugin. And half the size of a fully loaded Txp with all Lang files. Ludicrous.

It uses Composer, and each gateway does too. All the gateway modules rely on the core OmniPay library. But if you do composer update on them all, guess what: they download a bunch of the same dependencies as the main library. Guzzle. PSR. Monolog. Laravel bits n bobs. Yahde yahde.

Each module is minimum 8MB, and they all use the same base code with a couple of specific dependencies. So, let’s say you want to offer WorldPay and PayPal. That’s OmniPay core library + 2 modules = circa 24MB.

What. The. Actual.

So I asked the question: can Composer be told that a load of dependencies are already satisfied “over there —>” (points to core library) to avoid downloading the same ones that are already provided.

Honestly, you’d think I’d suggested brushing my teeth after drinking orange juice. The vitriol. The vitriol. e.g…

You’re making it deliberately hard for yourself.

Why should anyone care about 24MB?

It’s nothing compared with the convenience of keeping all the gateways siloed.

And so on.

Well I tell you, it matters to me. And I still haven’t solved it. But I will.

I want each gateway to be its own tiny bolt on. Yes the overall plugin will likely be bigger than Txp itself, but I’ll do my damnedest to make it as small and efficient as I can. Because it matters. And your post gives all the reasons why.

Assuming everyone has terabytes of available space and gigs of spare bandwidth is bordering on negligence, imo.

I’m working closely with someone else who loves Txp as a platform. He drafted in a third party to do some additional integration and, every week without fail, the guy asks him to consider moving his site to WordPress. Because there’s an integration plugin for it already, and this weird Textpattern thingy is a scary unknown. We both just smile and say “no thanks”. Not because it wouldn’t work. But because it wouldn’t work as well. As fast. As efficient. As easy to maintain. As tinkerable…

So, yes, tldr: Posts like this make me proud to be part of this CMS and the sweat we go through to keep its lightweight elegance at the centre of development. It’s awesome to know that we can deliver tangible value to people with website needs at any scale, without the traditional weight associated with similar projects.

Thank you for the props.

jakob · Today 09:00:21

I can only echo those sentiments.

Bloke wrote #343312:

… as a person who came from an era where you had to squeeze every byte of performance out of 5KB …

That made me laugh. I couldn’t help thinking of this (YouTube) 😂

Can Composer be told that a load of dependencies are already satisfied “over there —>” (points to core library) to avoid downloading the same ones that are already provided.

I’m not sure you can. There’s the global attribute for using composer packages system-wide but that sabotages the idea of having project-specific config files that you can share among a team or reinstall to a new server. In your particular case, the duplication problem may also have to do with how the library is architected and not just composer.

That said, might something like composer merge help by combining different sub-level composer.json files into a single top level composer.json?

I’m not sure whether anyone has done the equivalent of what pnpm has done for npm in the composer arena?

… Why should anyone care about 24MB? … Well I tell you, it matters to me.

I agree with you, of course, especially in relation to the txp core installation. That said, the new thumbnail creation routine can lead to significantly larger overall installations depending, of course, on the volume of images a site has and how many intermediary sizes you create for a srcset*. The 4,5MB installation size is exceeded by quite a wide margin, though you are right that things like the /images/ and /files/ directories are not part of any site update routine.

We’re still way smaller than some typical WordPress installations – a recent relaunch of a site that was formerly on WP has dropped the installation size to about 18% of what it formerly was, with around 3-4x more site content and new functionality.

*I’ve also found the internal resizing mechanism sometimes makes larger thumbnails than the original files.

Textpattern CMS

Textpattern CMS support forum

#1 Yesterday 09:44:42

An unsolicited "thank you"

#2 Yesterday 10:49:21

Re: An unsolicited "thank you"

#3 Today 09:00:21

Re: An unsolicited "thank you"

Bloke wrote #343312:

Board footer