Ten thousand reasons to use Textpattern
textpattern.com
textpattern.com
Services pitching "lifetime" seem to either wildly miscalculate the effect of pathological usage, fail to do accurate math on support, or are betting on shifts in the pricing of storage/bandwidth or computer that fail to emerge.
There's a lot of justifiable angst around "everything becoming a SAAS" but if I'm comparing services and betting which will be around in a year: I'm paying the monthly fee.
Great to hear Textpattern is still around. Loved it for its simplicity, easy customization and a friendly community.
That sounds a lot like:
Am I close?
Edit: it was you!–
https://www.textplates.com/2007/08/01/the-results
>Loved it for its simplicity, easy customization and a friendly community.
It's still simple-ish, lots of previously external plugins have been merged into the core, and the community is friendly, helpful and mostly harmless.
The main differences would be that in Processwire, you don't even need to install plugins, as all different types of displays are so easily created from scratch in the pure-PHP templates, using PW's extremely awesome jquery-like API for getting content (see the cheatsheet for an idea: https://cheatsheet.processwire.com/).
The community is great too.
From the post, I understand textpattern might allow editing designs from the UI as well though? That'd be nice... although upon thinking about it, such a feature could also be implemented with a few lines of code in ProcessWire, exposing a field for the UI, that would be processed in the php templates.
Yes, everything is stored in the database, and Textpattern has an integrated text editor for templates and CSS, with a rudimentary form builder (basically search for txp tags and drag them in).
https://textpattern.com/weblog/textpattern-cms-470-released-...
Theme components are import-able and export-able via the file system, which makes it more portable.
Bit surprised it's still alive, supports modern php - but apparently still require mysql/MariaDB - no sqlite, no postgresql support?
Still, if it ever saves me from managing WordPress with its awful plug-ins... I could see admining a dedicated mysql instance being worth the effort...
>I thought WordPress had squashed tp long ago.
Wordpress is much more widely-used. Textpattern is still around!
Edit: I almost forgot about this:
https://wordpress.org/news/2006/04/wordpattern/
>supports modern php - but apparently still require mysql/MariaDB - no sqlite, no postgresql support?
Correct. MySQL and store brand remixes mostly work just fine, no plans for SQLite or PostgreSQL as far as I know. Pull requests are welcome!
And as for sqlite - it would allow for even simpler setups (and quite[1] easy backups).
[1] via the backup dot command for example https://stackoverflow.com/a/34577922
Sadly not. We haven't made the jump to PDO (yet) and still use some MySQL-specific database features, such as ordering by FIELD. Once we wean the core code off that and schedule in the migration to PDO with all the prepare/execute goodness that brings, we'll support whatever database engines that PHP offer under PDO.
It's one of those things that's always overlooked in the "ain't broke so don't fix it" camp. But I know it needs doing. One day...
Take this with a big grain of salt, but I vaguely remember tp not being great at using prepared statements / safe quoting provided by the db driver - has that been improved (if it ever was a problem)? Is it easy for plug-ins to accidentally open up to sql injection?
Nope, we don't use them yet. Bane of my life. We rely on all core calls and plugin authors escaping content before calling our DB layer.
That has to change and will be part of the move to PDO. It's just a lot of faff work and there are always shinier things to work on.
I've been secretly hoping that some kind soul will do it and issue a Pull Request. But maybe I should stop being lazy, bite the bullet and do it myself!
I had a nagging memory of some troubles from bugtraq or an equivalent list (mind, many, many cms and blogs had trouble with sqli..).
I am a bit surprised that hasn't been (universally, permanently) fixed in the last decade, though.
What could you do in TextPattern today that you couldn't do with WordPress?
>What could you do in TextPattern today that you couldn't do with WordPress?
Honestly? Nothing I can immediately think of, given the vastness of Wordpress and its ecosystem of plugins, themes, etc.
We like efficiency, we like performance, we like people who like to write. We're a good community overall. I am involved with Textpattern mostly because of the people, not the code.
My dream would be Textpattern as the admin/author facing side, and then static site generation from that. I don't think there is a good plugin for that, yet.
If so, it should be easy enough to build a Textpattern sitemap scaffold with all the pages / articles / etc and then run a generator against it to spit out the files.
I have no idea how hard it would be to write such a plugin. Never looked into the dev side of TP, only used it back then.
It's a niche idea, sure. Most people would want to use a "proper" SSG anyway.
Edit: Actually, we two already talked about that here: https://news.ycombinator.com/item?id=23050113
You probably don't remember, either? :-)
Actually I did, I just didn't want to make it awkward!
One of the other devs has put together etc_cache which rolled in some static-site-esque goodness. http://www.iut-fbleau.fr/projet/etc/index.php?id=52
It's not a true SSG but intelligent cache based on the database knowing what's changed and what hasn't. Might be worth a look for your next project. Coupled with the fact you no longer need to do the staging server dance, iterating or redesigning is a lot more streamlined than it once was.
See: https://textpattern.com/weblog/the-end-of-the-web-developmen...
We'd love to see what you can do with Textpattern since you last dabbled.