Hello Themes!

Bloke · 2017-12-22 22:05:16

After much work, primarily by our very own NicolasGraph who has done so much to push forward the concept of flat-file editing in his plugin oui_flat, we are proud to announce that the ability to apply Themes in Textpattern is a reality.

We’re still going to be tinkering a little under the hood over the coming weeks to optimise it, finalise the callbacks and get the language strings in place, but from a workflow perspective this is our first stake-in-the-ground towards a brighter future for the platform. We’ll expand on this groundwork in future releases.

If anyone fancies taking it for a test drive, feel free to grab the repo or try the development demo when it’s synced in a few hours.

I’ll write some in-depth blog posts about it very soon to introduce the concepts of what it is and, more importantly, what it isn’t (yet). Full documentation will follow closer to release.

We hope you like this Christmas present. Sorry it’s taken 12 years to add the feature :-)

bici · 2017-12-23 07:56:00

Bloke wrote #308405:

After much work, primarily by our very own NicolasGraph who has done so much to push forward the concept of flat-file editing in his plugin oui_flat, we are proud to announce that the ability to apply Themes in Textpattern is a reality.

We hope you like this Christmas present. Sorry it’s taken 12 years to add the feature :-)

The 12 years of Textpattern Christmas

jpdupont · 2017-12-23 08:34:34

Nicolas and devs, thank you for all this great work!
Very good Christmas to all and a great new year!

I try the export function on my default theme, and I get this warning or error message.
Indeed, in themes \ default, there are a lot missing pages, forms, styles …

Why name unsafe while most of my names are built on the same structure: 2007_v3 _….

skin_exported: default
page_name_unsafe: (default) 2017_v3_main, loadimagesFROALA
form_name_unsafe: (default) 2017_v3_tags_list, 2017_v3_article_image_galerie, 2017_v3_table_sort_liste_album, 2017_v3_piwik, 2017_v3_image_random, 2017_v3_modal_script, 2017_v3_recherche_form, 2017_v3_search_results, 2017_v3_google_analytics, 2017_v3_video, 2017_v3_body_class, 2017_v3_contenu_agenda, 2017_v3_menu_accordeon, 2017_v3_album_flickr, 2017_v3_contenu_error404, 2017_v3_agenda, 2017_v3_contenu_accueil, 2017_v3_js_script, 2017_v3_article_image_hero, 2017_v3_header_ban_menu, 2017_v3_head, 2017_v3_footer, 2017_v3_menu_secondaire_agenda, 2017_v3_contenu_article_seul, 2017_v3_contenu, 2017_v3_VIDE, 2017_v3_contenu_recherche, 2017_v3_menu_secondaire_copy, 2017_v3_sections, 2017_v3_menu_secondaire, 2017_v3_contenu_liste_par_tag, 2017_v3_contenu_newsletter_2, 2017_v3_contenu_newsletter_3, 2017_v3_contenu_newsletter
css_name_unsafe: (default) 2017_v3_default

phiw13 · 2017-12-23 09:04:24

1. Congrats to Nicolas for bringing this about!

2. Are there any reason why one can’t export pages and forms that contain capitalised letters (same warning as jpdupont above)
Examples: a camelCase name page: downloadSection or a form: image_SVG.

Similar named pages/forms did import correctly a few days ago. I don’t remember running into this while exporting while testing the branch (but I maybe the test I ran had all lowercase names, not sure).

Last edited by phiw13 (2017-12-23 09:06:31)

Pat64 · 2017-12-23 10:35:08

Sorry for my French:
“Bravo Nicolas ! Trop bien.” ?

Just an advice:
Be careful with the default checked “Remove extra templates” box. With a previous version (unstable, not this one), I lost all my work (forms) within my theme development when I tried to export it…

colak · 2017-12-23 16:43:00

Bloke wrote #308405:

After much work, primarily by our very own NicolasGraph who has done so much to push forward the concept of flat-file editing in his plugin oui_flat, we are proud to announce that the ability to apply Themes in Textpattern is a reality.

A wonderful xmas announcement. Way to go!!!

Bloke · 2017-12-23 17:59:24

For anyone experiencing the ‘unable to export’ thing with unsafe names, we might have to relax the regex or use sanitizeForFile(). We’re currently restricting it to lower case names only with underscores, hyphens and dots, with numbers permitted anywhere except the first character (which is why jpdupont’s 2017_* names are rejected).

We had a discussion about it a while ago, but at the moment the regex appears to be lopsided: it’ll allow import of mixed case assets but not export. That should probably be tweaked so it’s symmetrical.

In retrospect, I can’t see any reason to forbid upper case characters, given that we permit them when saving in the UI. If we were making Txp class or function names out of the names, then we would have to forbid numbers in the first character, but I don’t think any file system has this restriction, so we should be okay to lift this.

Ideally we should permit camelCase and snake_case and numbers in any position, and any combinations thereof. But anything with any other characters that might potentially break a file system should be outlawed at export/import.

Maybe Nicolas found some corner cases that meant there was a very good reason to restrict this to the current filter. If not, I suggest we widen the pattern a little and also add the warning on save of any asset if the name doesn’t conform, so that people know it’s okay to use internally but if you try to export it, it’ll fail.

At the moment, when saving an asset in the UI, we only forbid < > & " ' characters. I think we should continue this (for backwards compatibility) but also perform a secondary check to see if it’s likely to fail an export too. And in that case, issue a warning on save.

Bloke · 2017-12-23 18:08:19

As a stop-gap, I’ve just widened the permitted regex to this:

[a-zA-Z0-9_\-\.]{0,63}

so all the above assets should now be imported/exported correctly.

We’ll look into warning when saving Pages/Forms/Styles in case you use something outside the permitted range at some point soon.

Last edited by Bloke (2017-12-23 18:09:38)

bici · 2017-12-23 19:04:48

michaelkpate · 2017-12-23 19:17:58

Bloke wrote #308405:

Sorry it’s taken 12 years to add the feature :-)

Technically, it is 13. But who’s counting?

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. – 1.0rc1 Released

Thanks to you and everyone who contributed.

It’ll be ready when someone writes it. Simple as that. – Template Manager

I, for one, am super-excited.

phiw13 · 2017-12-24 00:30:19

Bloke wrote #308417:

In retrospect, I can’t see any reason to forbid upper case characters, given that we permit them when saving in the UI. If we were making Txp class or function names out of the names, then we would have to forbid numbers in the first character, but I don’t think any file system has this restriction, so we should be okay to lift this.

I’m not aware of any file system that has issues with valid UTF8 characters. The only character that macOS disallows in a filename is the column : (it is treated as path separator internally). I think some UNIX variants had the same restriction. Not sure about Windows OS.

At the moment, when saving an asset in the UI, we only forbid < > & " ' characters. I think we should continue this (for backwards compatibility) but also perform a secondary check to see if it’s likely to fail an export too. And in that case, issue a warning on save.

Yes, warning people about the issue when saving an asset will probably be a good thing – form names written with CJK characters or emoji?

Your new regex works fine for me now. Assets with an uppercase character or starting with a digit export correctly.

phiw13 · 2017-12-24 03:52:29

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

From the Themes panel, select the theme and using the multi-edit widget, chose “duplicate”.

Warning "Invalid argument supplied for foreach()"
in /Users/username/Sites/_txp472/textpattern/vendors/Textpattern/Skin/AssetBase.php at line 347.

The theme duplicated correctly (green message box) and nothing was missing. and yeah, it is a warning.

Note also, duplicating that copy worked perfectly.

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?

Textpattern CMS

Textpattern CMS support forum

#1 2017-12-22 22:05:16

Hello Themes!

#2 2017-12-23 07:56:00

Re: Hello Themes!

Bloke wrote #308405:

#3 2017-12-23 08:34:34

Re: Hello Themes!

#4 2017-12-23 09:04:24

Re: Hello Themes!

#5 2017-12-23 10:35:08

Re: Hello Themes!

#6 2017-12-23 16:43:00

Re: Hello Themes!

Bloke wrote #308405:

#7 2017-12-23 17:59:24

Re: Hello Themes!

#8 2017-12-23 18:08:19

Re: Hello Themes!

#9 2017-12-23 19:04:48

Re: Hello Themes!

#10 2017-12-23 19:17:58

Re: Hello Themes!

Bloke wrote #308405:

#11 2017-12-24 00:30:19

Re: Hello Themes!

Bloke wrote #308417:

#12 2017-12-24 03:52:29

Re: Hello Themes!

#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!

Board footer