Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#109 2015-06-26 08:59:27

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

philwareham wrote #292114:

As far as I know Textpattern is unique (and not in a good way) in using database to store template files.

And as far as I know, Txp is one of the fastest CMSs out there. Coincidence? ;-)

Can other CMS codebases be dissected to help understand how they solve this problem?

Yes of course, but they don’t have the same issues. The problems in Txp are:

  • We have a loose API layer which makes calls to the DB. Most plugin authors probably use it, but it’s not enforced. So any plugin that talks directly to MySQL (or uses safe_query()) will break if we rip out the DB tables. safe_query('INSERT INTO txp_page, SET ...') BOOOOM!
  • Keeping both DB and disk-based templates means backwards-compatibility is preserved but means there needs to be a way of keeping them in sync. rah_flat kind of solves it, but does away with the Admin panels in the process. I’m keen to keep those. Plus it has the potential to erase stuff if you tinker with production status. That’s not something I’m willing to risk in the core unless it’s made absolutely clear what will happen if you do X while your site is in Y state, because it’s a support nightmare.
  • Deciding which is the Master copy. I touched on that in the post I linked to above, by implementing a timestamp column in the DB. To disambiguate, we could best guess or use timestamp comparison (which could slow things down, depending on when you do it). Or we could offer a pref (“Fetch templates from file system? Yes/No”) which would then govern what happens when tags and Txp runs. Both require tag code changes (not massive, but it makes them more complex to read from one of two locations) or DB layer changes such that it can do something different only if the table being referenced is txp_page, txp_css or txp_form. Bit messy.

I’m sure it’s all doable given enough thought, we just need to figure out the best way to do it, preserving as much continuity as possible, with minimum exposure to “shit, why are all my templates now blank?!”

It’s the single biggest hurdle to having a useable theme system really. I see it as essential otherwise themes won’t happen.

Simple themes can happen without it, no problem. A new column in the DB per table and a new Presentation panel for importing / exporting / managing and we’re golden. If we inserted everything into the DB tables, your local /themes/abc_theme directory could be deleted once imported with no impact on the site.

This way, any changes you make in the admin interface alter the DB tables only and won’t make any changes to the file system until exported. Any changes you make in the files wouldn’t be auto-reflected in the DB until you re-import them.

Thinking out loud, although it’s one extra step in either direction, that might be a nice way round it. Means you have total control over what’s synced and when without any guess work or complicated code. And if we had some indication in the admin side which was “ahead” (based on timestamp) then you have a nice way to know which side is most current and can take appropriate action, perhaps right there on the Pages or Forms or Styles panel (maybe even an import/export button for the current individual Page/Form/Style). Who knows.

Regarding security of the themes directory, you could allow users to change name/location just as they can with files/images directories.

Yes, we’d do that so you have the option of taking them out of docroot, good idea. I meant regarding directory permissions, sorry. If Txp creates the directory with 644 permissions when you install it and a particular host doesn’t allow reading/writing that way, you won’t be able to successfully use Txp out of the box. At least with /files and /images there are no issues until you come to use them or check pre-flight diagnostics and find you get a Cannot write to... message. If the host is configured such that it requires 755 or 777 to even read the folder, let alone write to it, you won’t see anything front-side besides error messages.

Is that a real-world concern? Maybe, maybe not. Other CMS systems work, so it must be solvable. We could certainly code round it: Ruud has some nice idea which I totally agree with (see reply to my above link).


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#110 2015-06-26 09:13:07

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,547
Website GitHub Twitter

Re: Textpattern themes: a plan

OK, so it looks like realistically we still have the templates in the database then, it’s just how they get to and from there into the theme directory flat files which we need to sort out a nice solution to.

An import from flat/export to flat button could work I think. It protects both sets of files from accidental overwrites to a certain extent (with a suitable warning message when you press the button).

The initial theme (the Textpattern default one) could already be loaded into the database at install as default along with supplying the flat files. That would at least give some protection against risk of having no templates out of the box. Users could maybe override that at install time, with their own themes.

Offline

#111 2015-06-26 09:25:56

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

philwareham wrote #292123:

An import from flat/export to flat button could work I think.

Yeah, simple and keeps you in control whichever way you work. Can’t believe it’s taken me 110 posts to think of it. But that’s the beauty of open discussion sparking random thought trains!

The initial theme (the Textpattern default one) could already be loaded into the database at install as default along with supplying the flat files.

Yes, that works well.

Users could maybe override that at install time, with their own themes.

Now that’s something I’d really like to do, and it’s been mentioned before somewhere. Having a nailed-down /themes folder at setup time — we know it’s going to reside in the default root location on install, right, or maybe the pref could be set during setup? — gives some lovely opportunities to drop themes in there and have them inserted into the DB immediately.

In fact, one could argue that we could actually strip out the default template code from the DB for new installs and have it live in the /themes folder. Then the install process just inserts into the DB whatever themes it finds there. Great for new builds and customised setups — and from a code perspective all it’s doing is calling Theme->import() on any folders it finds, so no extra code required.

Slightly risky if you don’t have anything in that folder or it breaks for some reason. Maybe if we detect there’s no data we fallback on the hard-coded default theme info. So it acts like today, but isn’t auto-inserted in the DB unless the end of the installation is reached and the tables are empty. Means’ wed need to keep the two in sync during development, but that’s less hardship then the prospect of someone installing Txp and having no template!

EDIT: There’s still the question of Section assignment. Presumably installation is a special case and we would need to assign Pages/Styles to Sections — at least for the default theme, with an ability to specify Section assignments in the theme itself, if that theme uses the definition of a Template as Bert outlined.

Iiiiinteresting….

Last edited by Bloke (2015-06-26 09:32:32)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#112 2015-06-26 09:38:08

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,547
Website GitHub Twitter

Re: Textpattern themes: a plan

Bloke wrote #292126:

In fact, one could argue that we could actually strip out the default template code from the DB for new installs and have it live in the /themes folder.

I’m fine with that, but just was thinking of a safeguard fallback of having something already loaded in database in case an import from theme directory fails at install for whatever reason.

i.e., the default theme is already in database and as flat files, but if you select a different theme at install it wipes that and uses the desired theme, unless something goes wrong. Dunno really.

Offline

#113 2015-06-26 09:46:52

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

philwareham wrote #292127:

the default theme is already in database and as flat files, but if you select a different theme at install it wipes that and uses the desired theme, unless something goes wrong. Dunno really.

Yeah, any or all of the above would work too. It’s just code.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#114 2015-06-26 15:50:02

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

Bloke wrote #292097:

try to directly call any mysql_ functions after PHP drop support entirely.

Which is slated for PHP 7 this year when all deprecated functionality from 5.x will be dropped. And they reckon that with the alleged 2x(ish) performance increase, hosts will be scrambling over themselves to upgrade us all sharpish so they can get more users on the same hardware. Whether that happens in reality remains to be seen.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#115 2015-06-26 16:03:46

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,547
Website GitHub Twitter

Re: Textpattern themes: a plan

Would this framework be of any use?

Offline

#116 2015-06-26 17:06:51

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

philwareham wrote #292143:

Would this framework be of any use?

Yeah I’ve been using Fat Free for six months now and love it. If ever it came down to rewriting Txp, I know where I’d start… :-) It’s blindingly fast and small. Even with every optional package installed (including geo support) it weighs less than 3MB and imo it does more, better, and more flexibly than any of the big hitters out there that I tried and hated (Symfony, Laravel, Cake to name three). It has its quirks — occasionally difficult-to-trap error conditions, for instance, which takes some getting used to — but on the whole it’s a game changer for me.

But integrating it now at this stage is not so simple. It does things quite differently to Txp in many respects, and isn’t completely compatible with our vendors autoloader setup without a fight.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#117 2015-06-30 01:28:37

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,374
Website GitHub Mastodon

Re: Textpattern themes: a plan

I have been lurking on this thread but I finally found what I was looking for in the archives:

One thing I was hoping to get in for this release, but it’s not quite there yet, is a themes engine I’ve been working on: this allows simultaneous installation of pages, stylesheets and forms through a simple installer much like the one used for plugins. Look for it in an RC or two. – Dean

I have to say I have been looking forward to this for a long time.

Offline

#118 2015-06-30 03:44:36

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Textpattern themes: a plan

michaelkpate wrote #292314:

I have to say I have been looking forward to this for a long time.

Dang, you’ve waited for a long time Michael – 2004-09-20 08:47:30

I registered on the forums in November of 2005, by that time Dean had left, never saw him make a forum post.

From day one, coming from a CMS where loading a “Skin” was trivial, I was perplexed.

Here’s to making your wish come true, fingers crossed and all that.

Offline

#119 2015-06-30 08:16:10

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

michaelkpate wrote #292314:

Look for it in an RC or two

Or twenty…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#120 2015-07-12 23:51:13

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,614
Website GitHub

Re: Textpattern themes: a plan

A chunk of the groundwork for Themes has been laid in its own branch on Github. Right now you can create a bunch of Pages, Forms and Styles under different Theme names on the admin side. The front side doesn’t know what to do with them yet (if, for example, you call two Pages the same name it’ll just get confused), but you can switch between them on the admin side and edit them as if they were separate entities. I have some markup issues that Phil’s helping me out with, so the UI isn’t clean yet, but functionally the admin-side portion works.

Now I’m at a junction point: what to do with Sections. I know we said that Themes in the first instance weren’t going to target Sections, but this does impact how themes are switched in and out, so it needs to be decided now. We have a few options which I’ll critique here:

Option 1: Leave the txp_section DB table roughly as it is

This entails adding only a theme column to the table so that you can assign a Theme to that Section. When Themes are installed from a package, they will only install Pages, Forms and Styles against the Theme’s name. It will then be your job to go to your Sections panel and assign them — either one by one, or using the multi-edit.

Pros:

  • You are in complete control over which themes get installed where on your site. You could, for example, install two themes and assign one to your default, archive and blog Sections, and a different theme to your portfolio Section.
  • Backwards compatible, to at least some degree, with plugins that use this table.

Cons:

  • Not able to do this automatically from the Theme bundle (yet?), which means even “out of the box” installs would need manually assigning to Sections.

Option 2: Multiple Sections

Permit a Theme bundle to add new Sections of their own name, against its own Theme name. So you could have multiple default or archive Sections, for example.

Pros:

  • Themes could auto-install Section information assigned to its own Pages, Forms and Styles but they wouldn’t become “active” until you switched them over. Great for “instant gratification”: install and enable.
  • Backwards compatible (ish) with plugins as long as they are modified tor respect the theme column.

Cons:

  • If you already have content assigned to the Sections against your old Theme, they’d need moving over en-masse to the new Theme (using Article multi-edit) before they’d show up on your site.
  • If you want to create a new Theme on your existing site, you need to duplicate the Section information: name, title, syndicate, on front page, etc. for each Section you have already defined: an overhead.
  • Complicates the Write process: need to assign an article to a Theme/Section combo, not just a Section.

Option 3: New table for Section assignments

Break out the page and css columns into their own table (along with Theme name) and link it to txp_section. This permits one Section to “own” multiple Pages and Stylesheets.

Pros:

  • During installation a Theme bundle can add its own Page/Styles assignments to existing Sections without impacting the current site.
  • Switching a theme just involves changing one “master” theme switch: instant gratification.
  • Content remains assigned to its existing Section: no need to move anything.

Cons:

  • Only one Theme can be active across the entire site at any one time: no mix and match.
  • Not backwards compatible with plugins at all.

In all cases except Option 2, at this stage I would NOT make it possible for a theme bundle to add new Sections. Depending on the option selected above, a theme might be able to alter the Page/Style assignment, but that is as far as it would go. In the next iteration of Themes (when Packages and other things such as plugins are considered), some installation wizard could present a list of things the importer is going to do and you could choose if you wanted it to create new Sections at install or upgrade plugins etc, but that’s not the current scope. This is the keep-it-simple drop.

There is a sort of fourth option, a modification on Option 3, that encompasses renaming the table that Txp uses for Sections, and then making a database View with the same name as the current Theme/Page/Style. This means existing plugins continue to operate under the “currently selected theme only”. Such plugins would simply “see” the View, which would look exactly as it used to. This, however, requires your MySQL database user to have some advanced privileges. For those of us who just Assign All privs to our users, great. For those that set their things up tighter, the priv changes would need to be made before upgrade or the upgrade will bork, because current Textpattern does not require CREATE VIEW privs.

So, the choice largely comes down a trade-off between:

  1. being able to one-click switch a theme (one theme per site only)
  2. using multi-edit to switch themes by hand (multiple themes are possible per as many Sections as you like)
  3. content assignment
  4. backwards compatibility

Ultimately, are we aiming themes at the “install theme and press a button to make it active, site-wide” crowd to get a new Txp install up and running quickly, or the “install/upgrade, keep my site as it is, and let me migrate to the installed theme(s) when I’m ready” crowd? The latter could still be done in one go — with multi-edit to assign a Theme to Section(s) — but it’s not via a single Theme Activate button / select box combo.

I’ll come out and say I’m not a huge fan of Option 2 at all, but I’m torn between 1 and 3. These are probably not the only options, but it’s all I could think of for now. Someone might be able to come up with another option or two: in which case, please present them here.

Thoughts?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB