Testers needed: theme management in 4.8.3

gaekwad · 2020-08-20 18:35:27

github.com/textpattern/textpattern/issues/1538

During the development process for Textpattern 4.8.3, an issue with themes management was identified. This issue has been tentatively fixed, and in order to ensure this works as intended we are calling on testers to ensure the fix works in a wider variety of environments.

In the situation where styles are removed from a section and site, for example if styles are delivered from a CDN or other location, a subsequent import or export of a theme triggered error messages, and resulted in an empty styles directory for exports.

There’s an in-progress development build of what will ultimately become Textpattern 4.8.3 available for download here:

github.com/textpattern/textpattern/archive/4.8.3.zip

At the time of writing, this download includes the tentative fix made for the themes-related issue outlined above.

We would be grateful if you could test this build, paying particular attention to how themes are managed with the above scenario. Does it work as expected? Do you receive warnings and/or errors? Please test and let us know.

Finally, this issue is currently the only outstanding bug fix that’s being tracked for Textpattern 4.8.3. When we’re happy this is fixed, and assuming no further bugs are discovered in the process, Textpattern 4.8.3 will be coming soon.

Thank you.

Last edited by gaekwad (2020-08-21 06:57:48)

colak · 2020-08-21 05:12:26

Hi Pete,

Thanks! I’ll be checking this on Monday.

phiw13 · 2020-08-23 01:15:16

I will try to take it for a test-ride tomorrow as I have done some theme related work that need export etc.

But I am not sure I understand what the actual issue is here? Is it a problem when no stylesheet is defined under the styles tab?

gaekwad · 2020-08-23 13:00:36

phiw13 wrote #325526:

But I am not sure I understand what the actual issue is here? Is it a problem when no stylesheet is defined under the styles tab?

I’ve interpreted the issue as best I can – I’m also not entirely sure what the issue is from the report, but you may find the answer within: github.com/textpattern/textpattern/issues/1538

It’s possible Phil or Oleg could shed some light.

phiw13 · 2020-08-24 02:26:03

gaekwad wrote #325528:

I’ve interpreted the issue as best I can – I’m also not entirely sure what the issue is from the report, but you may find the answer within: github.com/textpattern/textpattern/issues/1538

It’s possible Phil or Oleg could shed some light.

Yeah, I had read that GH ticket and did not understand the current state of what happens and what should happen, that is why I asked…

anyway, in a quick and very basic test, the things still seem to work fine on theme export for my existing structure. That structure stil has a stylesheet entry under the “Styles“ tab, the ‘original TXP-default’™ stylesheet now completely emptyfied and not referenced any where except under the “Sections” tab.

zero · 2020-08-24 08:59:53

Similar to phiw13, on importing a theme without a styles folder, I get a warning about cannot read from the styles folder, but the rest imports OK. I could assign a section and duplicate without problem. On export, with empty checkbox, it exported the same structure. On export, with checkbox ticked, it did as expected and created a styles folder with emptified default.css. So it all seems to work as i would expect it.

colak · 2020-08-24 09:28:07

I get the same error. The main question is, since the support of flat files, I cannot understand why would anyone prefer to have the css hosted on a different, not accessible by the db, directory.

phiw13 · 2020-08-24 09:35:16

colak wrote #325541:

[…]I cannot understand why would anyone prefer to have the css hosted on a different, not accessible by the db, directory.

Oh, i don’t really know why my highly optimised and minified stylesheets can be of any use in the DB, except for linking to it, and even then.

But I am not really a theme guy, to be honest.

Last edited by phiw13 (2020-08-24 09:37:44)

etc · 2020-08-24 11:25:43

I guess (Phil might con/infirm) the main question is what to do on export/import with sync when styles assets (either db or disk) are missing. Should we issue a warning? delete the target’s assets? Should we do the same for forms and pages too? Initially, these three folders were supposed to always exist, but with flat styles and pageless sections they become optional.

This said, it’s an edge case and not 4.8.3 blocker imo.

Bloke · 2020-08-24 13:02:22

etc wrote #325543:

what to do on export/import with sync when styles assets (either db or disk) are missing.

For import with sync, the process was planned to be:

Take assets from disk, overwrite any matching content in the DB that already exists, and delete any assets in the DB that aren’t in the incoming theme structure.
If one of the directories is missing OR an ‘essential’ asset is missing from the incoming theme structure, create corresponding placeholder assets in the database for the missing content, with commented out content to explain what it is.

For export with sync:

Take assets from DB, overwrite any matching content in the filesystem that already exists, and delete any disk-based assets that aren’t in the DB’s theme structure.
If any of the assets are missing OR an ‘essential’ asset is missing from the DB’s theme structure (e.g. you’re not using Styles), create corresponding placeholder assets in the filesystem for the missing content, with commented out content to explain what it is.

In other words, the integrity of the structure should remain, even if the content is missing. Special consideration is afforded to the assets that are deemed ‘essential’ for Txp’s operation.

Over time, once we figure out whether we want to keep the notion of ‘essential’ assets, we can maybe relax this so that missing directories are skipped. But even at that time, if you’re sync-importing a theme and it has no /styles, for example, and your DB has some, your DB should have no assets in it after import. This maintains the expectation that if you opt-in and check the sync box, it is a destructive process.

Last edited by Bloke (2020-08-24 13:03:51)

michaelkpate · 2020-08-24 14:33:35

phiw13 wrote #325542:

Oh, i don’t really know why my highly optimised and minified stylesheets can be of any use in the DB, except for linking to it, and even then.

I actually assumed everyone would be doing something like this:

    <!-- CSS
    ================================================== -->
    <link rel="stylesheet" href="<txp:page_url type="theme_path" />/styles/base.css">
    <link rel="stylesheet" href="<txp:page_url type="theme_path" />/styles/vendor.css">
    <link rel="stylesheet" href="<txp:page_url type="theme_path" />/styles/main.css">
    <link rel="stylesheet" href="<txp:page_url type="theme_path" />/styles/default.css">

I guess not.

The first three were included with the theme so I don’t actually edit them. The changes I do make are in default.

zero · 2020-08-24 16:12:05

When making my latest themes, I learned it was much easier for me and the user to use Michael’s method, and I think it was just old habits that stopped me doing it previously. I used
<link rel="stylesheet" href="<txp:page_url type="theme_path" />/styles/<txp:page_url type="theme" />.css">
and so could use the same pages with that code on all 6 themes. For theme makers it also means less instructions needed to give to theme users. By putting the assets in the styles folder too, it makes linking to them in the stylesheet simple. I will be doing all future themes the same way.

If you are not a theme maker, it still makes sense, imho, to have your site design images and fonts in the theme styles folder — less clutter and easy to do. I’ll ask elsewhere about whether other assets can work from there too.

Bloke · 2020-08-24 16:28:25

zero wrote #325547:

to have your site design images and fonts in the theme styles folder

You can do that, but I would be wary of doing so. Simply because Txp assumes stuff inside there is, well, stylesheets. And if you do a full export with sync, Txp is likely to trash anything in that directory that isn’t a css file.

Might be better to put your assets in a parallel directory (or directories), e.g.:

/themes/slim/forms
/themes/slim/pages
/themes/slim/styles
/themes/slim/js
/themes/slim/img
…

Or:

/themes/slim/forms
/themes/slim/pages
/themes/slim/styles
/themes/slim/assets/js
/themes/slim/assets/img
…

You can still refer to them using <txp:page_url/>. It also means that if you delete a theme from disk, those assets are guaranteed to be left behind because Txp doesn’t understand them as an official part of a theme.

EDIT: I’ve not tried it, but you might actually want this behaviour so when you delete a theme then all assets go too. Not sure if it does that. It might even leave them behind if they’re in the /styles directory, I’d have to check to be sure.

Last edited by Bloke (2020-08-24 16:45:16)

zero · 2020-08-24 16:34:35

Bloke wrote #325549:

And if you do a full export with sync, Txp is likely to trash anything in that directory that isn’t a css file.

I wrote:

Yes, I’ve been doing an export without the checkbox ticked.

I wasn’t entirely sure when I wrote that, so I’ve checked again, and found some very interesting results.

I transferred across a test theme which contained test.css and default.css in its styles folder. Also in the styles folder was a css folder which contained 4 other .css files plus more folders for several themes with various things inside those including some more .css files.

So in my remote Themes panel, I had the option to Import the ‘test’ theme, which I did. There was an amber message saying theme test imported and there are 4 css_duplicates (which were the .css files in the css folder and not already on my remote site). I assigned the theme a section and found that I had the option to give it any of the 6 styles — not just test.css and default.css but also the four inside the css folder.

I assigned the test.css to the theme and section and all seemed as normal. So I tried to delete the theme with checkbox unticked and this failed because the theme was using a section. Fine. I checked what that had done to my files and found that all were as when transferred PLUS there were now copies of the four .css files that were in the css folder directly inside the styles folder. Mmm.

I reassigned the section, so the test theme was no longer used, and exported to disk with the checkbox ticked. On checking, all files are just as previously.

So I go back and delete the test theme, with the checkbox unticked. ‘test’ disappears from the Themes list but on checking the files all 6 .css are in the styles folder and all other files and folders are as they were. There’s an option to import ‘test’ theme again, so I do so and get the same results as when I originally imported it, BUT this time 8 .css files are reported as css_duplicates — the four .css files in the css folder times 2.

So without assigning any sections I deleted the test theme again with the checkbox ticked. In an amber warning it says:
Themes deleted: test. Theme files deletion failed for: /path/to/themes/test.

On checking the files I find that all .css files have been deleted, in the styles and in the css folder and also there were some more in the other folders and they were deleted too. The Pages and Forms folders and contents have all been deleted too, and manifest.json. But everything else is intact — all the other folders and files within them. I THINK THIS IS A GREAT FEATURE!

It appears to me that your mapperzapper searches out all .css files, and pages and forms, but leaves the styles folder there if there are folders inside it. And probably would do the same with the pages and forms folders if they had sub-folders too. I like it!

Last edited by zero (2020-08-24 21:20:02)

phiw13 · 2020-08-24 23:22:15

michaelkpate wrote #325546:

I actually assumed everyone would be doing something like this:

I guess not.

Definitely not. That goes against my preference for separation of content and structure – and keeping “structure” files, aka TXP forms and pages separate from “resources” . And it probably is marginally slower than directly linking to a stylesheet / js file / …

Textpattern CMS support forum

#1 2020-08-20 18:35:27