Ramblings On A Multi-Site Textpattern Install

A while back, after running Textpattern on Place Name Here I got the bright idea to duplicate or syndicate (or whatever you want to call it) the web tech related postings over at the more focused ChunkySoup.net as a way to freshen that place up a bit. Sure, I could have just parsed the Atom feed from the originating site and then drop the results on the homepage of the other one, but what fun would that be… and it wouldn’t be particularly friendly either.

And thus began the Textpattern hacking.

The goal – to get two sites sharing the same articles, comments and feeds with different restrictions and presentations and with no manual work to keep in sync on a dat to day basis.

Now I’ve gone through the hacking process a few times, most recently to update the site to run off the 4.0 (and then before I could get it done the 4.01) codebase, and I’ve refined things to the point where they’re easy enough to explain. (clearly I hope). I won’t post code here, because specifics have changed a bit with different TXP versions, but I’ll try and outline what has to be done and where.

There’s really two changes at work here, first is to get 2 different sites with two different appearances, locations and configurations working from the same centralized content repository, and the second is to get one of those sites to only present a portion of that content (in this case, anything posted in the “web” category.

To get the two sites working off the same content, but looking differently we need to get them both access to the same database, and define some shared tables and some site specific tables. Those that each site needed on its own are as follows, the rest are shared:

• txp_css
• txp_form
• txp_log
• txp_log_mention
• txp_page
• txp_plugin
• txp_prefs

For each of these tables I duplicated them for the second install (using a postfix, as the is already a prefix facility in the code), added a method in txplib_db.php to clean up the table name generation and add the postfix found in the config.php file if the table called is in the subset defined above, and off we were. Almost. Duplicating the tables isn’t enough, for the second site we at least need to update the domain of the site in the prefs file so we can go in and manage the rest of the preference and template changes via the admin interface of each site.

Ah, but there’s a hitch! For the most part the textpattern data layout is clean and the separation of the data above for one site or the other went flawlessly – except for one field stored in the prefs table – last modified date. Somehow, probably for lack of a clearly better place, this value that got stuck as an entry in the site preference table. To work with this, it was necessary to add code in 3 or 4 places where that field may be updated to update it for both sites (txp_article.php, txp_link.php, comment.php). [note to texpattern maintainers: I suggest either storing this value someplace that is more representative of its association with the content, or alternatively writing a utility function to manage all updates to this field from a central place instead of having it scattered about .]

At this point, I’ll drop the modified files in the textpattern folder for both sites and, after editing their preferences, they should be up and running with their own looks, but with the same content, shared comments and seeing new articles and links as added.

The second part of the process took a little more knowledge of the code and tags behind TXP templates. It be wonderful if there was a way to restrict every article related tag (from article display, to next article, etc.) by category and have the work done for me, but it just wasn’t that easy. The standard method of including articles (the apt named article tag) is just too smart and relies too much on context to do it, and the alternatives (other tags, or plugins) though they may allow restriction by category just didn’t seem to offer the flexibility that the article tag does when dealing with article lists, pagination, viewing single articles and whatever other magic it works.

So off to modify a few queries. And when I say a few I really mean it. It was only necessary to modify queries in publish.php, and the files that generate the feeds (atom.php & rss.php) to only pull articles or references where either one of the categories matched the one I wanted to restrict the site to (“web”).

And thats it. As I noted above, TXP has matured enough, and a lot that recently, that the code is fairly clean and well organized and aside from the last modified date issue (which can just be turned off in the prefs anyway).

And one last note on version updates should you kids choose to try this at home, I still use PNH as the “primary” install (including not adding a postfix to the tables) so that I can run the stock update scripts if they change the database structure and then migrate those changes over to the other install. Have to then in and reapply my changes in the code, and I’m done and ready for testing in a few minutes.