Hello Themes!

jpdupont · 2017-12-24 12:12:33

With the latest version, and the patch of Stef, I was able to export my default theme, without more errors.

I have two questions:

What is the “remove_extra_templates” option for?
For me a theme is also sections (listed in the skin grid but not exported – why not in the json file -) and plugins, with their installation and settings. Many plugins are called from forms and pages. Is this planned / possible?

Sed-cleaner had a fully configurable companion file cleaner.php which allowed the installation of a series of indispensable plugins …

Last edited by jpdupont (2017-12-24 12:25:18)

Bloke · 2017-12-24 16:52:06

phiw13 wrote #308422:

A minor issue I encountered, after messing a little with form names (CJK characters, :,…), and then deleting those forms.

Thanks for the report. Where would we be without your awesome diligence!

Will play with this. At the moment the regex that finds files and checks if things are “valid” is a standard ASCII regex. I think this should be changed to a Unicode-aware regex using p{L} and things like that. That’s probably fairly easy but I’m not sure how mb_strlen() works in tandem with it.

For example, write a loooong filename (>63 chars) containing some multi-byte characters, sanitize the string using the Unicode regex, then truncate them using mb_strlen() to 63 characters and try to store the result in the MySQL table with its name field set to a max of 63 ‘chars’. What’ll happen? Could it get chopped off mid-byte in the last character? Will it try to store ‘more’ characters than there is space in the column? I’m not sure.

jpdupont wrote #308424:

With the latest version… I was able to export my default theme, without more errors.

Excellent.

What is the “remove_extra_templates” option for?

It deletes all assets first before the operation. So if there are any left over from a previous import (into the DB) or export (out to the filesystem) they will be deleted before the operation so the action is “clean”.

For me a theme is also sections

We’re probably going to call that a “Template”. See this post by Bert for an example of what we may be able to bring in future.

For now, it’s too risky to start automatically adding and removing Sections that may or may not already exist in a person’s Txp. And too much work (for now) to write an import/export wizard so people can choose which things to bring in and which to leave out. So we’ve gone very very basic and taken the least destructive path to fruition.

And this way, you get to preview your theme without anyone knowing about it before making it live, which is very useful to people who make incremental or step changes to a live site, as it means you don’t need to worry about making a staging environment and faff with syncing databases on go-live.

phiw13 · 2017-12-25 09:27:03

So, a couple of weird things I experienced yesterday:

Prelude: updating a live site from TXP 4.6 to TXP 4.7dev – server: Dreamhost + PHP 5.6

step 1: verify health site, set it to maintenance mode (smd_at_work). OK
step 2: upload the whole package of files + the ‘version_up’ theme folder (have to use the new toys! Thanks Oleg for evaluate and more).
step 3 update PHP to v7.1 (DH control panel). Then, update a couple of extensions.
step 4 Import new theme, verify that all new pages / forms work OK – done.

Flip the switch on the sections panel (that is actually a bit of work…) (and we’re still in maintenance mode) Everything should now use the new theme, right?

Out of curiosity, a check with Firefox – it shows the error_503 page as expected, BUT with a weirdness (at least to me): it uses the error_503 page template from the old theme, with the forms from the new theme (2 calls with <txp::output_form />). But checking in Safari all pages appear to use the new page templates. Some use different names from the old ones, some have the same name (ditto for form names); perhaps that is not a great idea.

Turn off maintenance mode.

Now for some more weirdness, part of which is user error, I think, and part I don’t know. Something might be related to my previous comment .

Back to the Themes panel, where I have 2 two themes: “default” and “new_theme”. First thing I open the “default” theme in the edit panel and change all fields. Here I made a maybe typo. For version I specified v1.1 – note the “v“. I think this confused the system. When saving I got this message (but all data was correctly displayed –as I had edited– in the table):

From this point on I could not edit that theme metadata anymore. Creating a copy failed as well. I tried exporting the theme, but that failed as well. Here is probably a user error, in that, when uploading all the files (“step 2” above), I set the permissions for the new_theme, but not on the parent themes folder (DH requires 777). Part of my export attempts woos probably stem from this, in that TXP apparently managed to create the old_theme folder + lock folder but could not do anything more. And having that lock folder caused some editing weirdness? But that is a guess, as at no point did TXP tell why the export failed (TXP was in testing mode, perhaps debug mode would have more verbose).

I fixed it… With Transmit I deleted the old_theme folder, then verified the permissions on the parent themes folder. But still no editing of that theme. I accessed the DB directly (Sequel Pro) and changed that version field. Editing was now possible, but not duplicating. Finally, I changed the name of some of the pages and forms that had capital letters to use only lowercase letters. That fixed it all. Exporting + duplicating worked as expected.

After all that I deleted the old_theme (all I wanted is keep it as a back up locally).

PS – Do I love to break beta software?

Bloke · 2017-12-25 15:04:24

Ah, regarding the 503 thing, I think Txp’s die handling tag probably needs changing to pick up the theme in use. Oversight on my part. Will try and fix.

The only issue is that the skin is tied to a Section but when a page is missing (for example) or issues another error page, there may not be a Section (as such). So how would we know which skin to check? We can fallback on ‘default’ for sure, but it should (at very least) use the skin_editing pref and pull the skin details from there so admins will see the correct error pages from their last-used skin. But I’m not sure what to do about the rest of the user base under general error conditions. Anyone just typing a bogus URL in needs to be directed to one of the error pages. e.g. Typing https://example.org/ytqwukklk into a browser that uses section/id/title permlink scheme: which skin would we use to return the error page?

As for the other thing, there’s probably an assumption made that the version is just numbers in the meta data. We need to sanitize that if it’s not done already. If it’s not that I’ll replicate your situation and figure out what’s going on.

Love having you around to highlight and help fix all this stuff. Textpattern would be far poorer without you, thanks.

Last edited by Bloke (2017-12-25 15:21:05)

Pat64 · 2017-12-26 09:16:49

Here is a strange behavior.
Starting with a fresh installation (latest 4.7-dev) and choosen the option “empty theme” (two indispensables page templates only: “default” and “error_default”), I can’t render any errors page: I’ve got a blank page without any HTML markup (even if I inject the content keeping from the ‘default’ website model).
Note: this seems not occurs if we choose a ‘normal’ installation with the ‘default’ website model and create a theme over it.

Last edited by Pat64 (2017-12-26 09:26:07)

Bloke · 2017-12-26 09:34:24

Pat64 wrote #308429:

I can’t render any errors page

Same issue as phiw13 raised above I think. We need to find a way to handle error pages from a theme somehow.

Pat64 · 2017-12-26 10:32:10

Fine.
Otherwise, themes support is super cool (and new tags very useful) ;)

Bloke · 2017-12-26 17:10:00

Should have fixed the error page scenario now. Please test.

Will do some more investigation into sanitizing the page/form names.

phiw13 · 2017-12-27 08:44:19

Bloke wrote #308437:

Should have fixed the error page scenario now. Please test.

The error pages seem to work fine now, as far as I can tell, at least for the scenarios I outline above (site in maintenance mode, user logged in, checked for 404; in other browser, the error_503 page displayed as expected). Haven’t had the opportunity to test Pat‘s scenario yet.

Pat64 · 2017-12-27 10:04:09

phiw13 wrote #308441:

The error pages seem to work fine now, as far as I can tell, at least for the scenarios I outline above (site in maintenance mode, user logged in, checked for 404; in other browser, the error_503 page displayed as expected). Haven’t had the opportunity to test Pat‘s scenario yet.

Yep. Tested: all works fine as expected!

Thank you lot, Stef ;)

Pat64 · 2017-12-27 12:41:55

Excepted: any call to forms doesn’t work within such an ‘error_default’ page template.

Bloke · 2017-12-27 18:52:00

Pat64 wrote #308446:

Excepted: any call to forms doesn’t work within such an ‘error_default’ page template.

Yes, that’ll probably fail for the same reason as the txp_die itself used to fail before I patched it: there’s no concept of “which theme” the system is using under error conditions.

I’ve got around it in the error handler code by guessing the theme (i.e. using the one you’re using as an administrator or the one that was in force just prior to the error being thrown or – failing that – the one set as default). We might be able to use the same logic here. The <txp:output_form> tag already falls back on “last used” (if it can), but doesn’t take into account the admin theme you may be testing or the default theme. I could add that.

Would it be generally useful, do you think, to add a theme attribute to the tag? It’d default to the best theme it could find, but you could temporarily override the theme that it chose if you wanted. It seems useful when I say it like that, but I’m not sure if it is in practice.

Any thoughts anyone?

Textpattern CMS

Textpattern CMS support forum

#13 2017-12-24 12:12:33

Re: Hello Themes!

#14 2017-12-24 16:52:06

Re: Hello Themes!

phiw13 wrote #308422:

jpdupont wrote #308424:

#15 2017-12-25 09:27:03

Re: Hello Themes!

#16 2017-12-25 15:04:24

Re: Hello Themes!

#17 2017-12-26 09:16:49

Re: Hello Themes!

#18 2017-12-26 09:34:24

Re: Hello Themes!

Pat64 wrote #308429:

#19 2017-12-26 10:32:10

Re: Hello Themes!

#20 2017-12-26 17:10:00

Re: Hello Themes!

#21 2017-12-27 08:44:19

Re: Hello Themes!

Bloke wrote #308437:

#22 2017-12-27 10:04:09

Re: Hello Themes!

phiw13 wrote #308441:

#23 2017-12-27 12:41:55

Re: Hello Themes!

#24 2017-12-27 18:52:00

Re: Hello Themes!

Pat64 wrote #308446:

Board footer