Feedback to: Textpattern CMS 4.6.0 beta released

philwareham · 2016-06-14 10:28:19

Bloke wrote #299710:

Yay, nice one.

Sure, I’ll do it at lunchtime. Do we want to go with a fixed location file, called custom.css? A different name? Or a user-specified filename? And what of .js? Worth adding a similar thing in there too, if I can figure it out?

A custom JS file would be of benefit to people, I’m sure. I don’t have a personal preference on how these files are labelled – the ability to have a user specified name makes sense, to lessen the risk of overwrites during upgrades.

Bloke · 2016-06-14 12:12:18

philwareham wrote #299713:

A custom JS file would be of benefit to people, I’m sure.

Done it in my local repo, along with the CSS. Works well; good fallback. Users don’t have to do anything besides add the custom.css or custom.js file to the theme’s relevant assets folder. But if they want to rename one, for example:

define('admin_custom_css', 'my_custom_file.css');

That will override the custom.css file name: best of both worlds. Likewise you can set admin_custom_js if you wish, or just use custom.js by default. Lots of scope for modding a theme without making a new one. Mmmm custom bot_wtc goodness :-)

Got any ideas on some JS functionality to include in custom-example.js? I’ll do a tiny bit more testing and commit this for now, but if you find any juicy JavaScript as an example of what people might want to do, add it to the repo as custom-example.js. Cheers!

phiw13 · 2016-06-14 12:19:00

Bloke wrote #299719:

Done it in my local repo, along with the CSS. Works well; good fallback. Users don’t have to do anything besides add the custom.css or custom.js file to the theme’s relevant assets folder.

So it will only work if a theme includes an assets folder ? Or if the user adds that folder ?
I’ve never used an assets folder on any project, personally.

Bloke · 2016-06-14 12:36:31

phiw13 wrote #299721:

So it will only work if a theme includes an assets folder ? Or if the user adds that folder ?

Currently it’ll only work in Hive or Hive Neutral! It’s part of the html_head() function, which core itself does not define. It’s down to the theme to do that.

The upshot is, you can benefit from this in two ways in your own themes:

extend hive or hiveneutral, create an assets/css or assets/js folder in your theme’s folder and tell your users to drop customisations in there, exactly like they would for a core theme.
modify your themename.php file, override html_head() with your own code and you have the option to do the same as the core does if you wish (copy ‘n paste, then tweak), with the extra flexibility to be able to define where you want those custom files to live inside your theme’s directory structure. Or not include them at all. Or allow multiple custom files, or, well, whatever you want: it’s your theme!

In both case, people can use the override filename feature if they wish, as long as in the second method you code support for it.

Bloke · 2016-06-14 12:43:44

Of course, the downside to having custom files reside in each theme is that you need to copy them over to your other themes… or symlink them from somewhere else. Otherwise, if you switch theme, you lose the customisations.

Having a central location would be grand (in a way¹), but that’s probably a much larger change to core, which is probably not such a good idea at this late beta stage. I could look into it, and though. And if it’s not a massive amount of effort, could give it a whirl.

¹ EDIT: but here, if you have theme-specific customisations, a central location isn’t such a good idea, as some misplaced code could break your other themes.

philwareham · 2016-06-14 12:53:59

Bloke wrote #299724:

Of course, the downside to having custom files reside in each theme is that you need to copy them over to your other themes…

I think this is the best solution personally. Customisations should be targeted at a specific theme – if you want to customise another theme either copy the customisations over or write new ones.

Bloke · 2016-06-14 13:01:48

philwareham wrote #299725:

I think this is the best solution personally.

I concur. And if someone’s hell-bent on sharing files, they can symlink to a central location outside of the admin-themes directory.

phiw13 · 2016-06-14 13:23:52

Bloke wrote #299723:

Currently it’ll only work in Hive or Hive Neutral! It’s part of the html_head() function, which core itself does not define. It’s down to the theme to do that.

Oh, I see what you did. OK, that is much easier to reuse / implement that I first understood, with the added benefit that a third party theme can customise the path. Cool.

phiw13 · 2016-06-15 11:55:52

Bloke wrote #299723:

Currently it’ll only work in Hive or Hive Neutral! It’s part of the html_head() function, which core itself does not define. It’s down to the theme to do that.

Ok. I have it running for Sandspaces (at least my local copy). Bits of copy, bits of paste, a couple of edits and it was all done. Thing works nicely – both the default custom.css and the user-decides-on-crazy-name.csscases.

Bloke · 2016-06-15 12:35:04

phiw13 wrote #299749:

Thing works nicely – both the default custom.css and the user-decides-on-crazy-name.csscases.

Thanks for testing. Glad it works.

gomedia · 2016-06-18 02:53:56

I have to admit that these recent discussions about customised themes have flown over my head, but that’s OK I’ll work it out one day.

However, can I make a general comment on placing user files in standard TXP subdirectories? And please shoot me down in flames, it’ll only allay my fears.

My concern is that the placement of user directories/files in standard directories make upgrading TXP releases more problematic.

For example, non-standard admin themes have to be put in textpattern/admin-themes, so now when there’s a new TXP release I can’t just replace the whole textpattern/admin-themes directory without destroying additional themes contain therein.

If it was set up so that to introduce custom themes there was a requirement to create a separate directory (e.g. textpattern/admin-themes-user), which didn’t come with the TXP distribution, but to which TXP referred then it would limit the risk of destroying something important during upgrades.

phiw13 · 2016-06-18 05:50:58

gomedia wrote #299823:

If it was set up so that to introduce custom themes there was a requirement to create a separate directory (e.g. textpattern/admin-themes-user), which didn’t come with the TXP distribution, but to which TXP referred then it would limit the risk of destroying something important during upgrades.

That is of course a concern. But then, anything inside /textpattern/ is at risk. For example if you update by simply dragging /textpattern/ from local to server through your FTP client (depending on how said FTP client is configured). Goodby config.php?

gomedia · 2016-06-18 06:02:23

Upgrading Textpattern is currently a relatively simple procedure – as detailed here:

Copy the contents of the textpattern folder to the server’s textpattern folder. You may exclude the setup directory, since it is only used for first-time installations.

The instructions are clear, i.e. “Copy the contents” of the Textpattern folder. By mixing custom files/directories in standard directories it now means that:

These instructions are now dangerously misleading
Steps to upgrade Textpattern will become more complicated

Do we really want to make life more complicated?

phiw13 · 2016-06-18 06:25:22

@gomedia

Up to Textpattern 4.5.7, one placed third-party admin themes in /textpattern/themes/ so there is no real difference, except for the location. OK, with TXP 4.6 there is an added complication, in that you can have a custom stylesheet or JS file inside admin themes folders.

gomedia · 2016-06-18 07:04:52

phiw13 wrote #299828:

Up to Textpattern 4.5.7, one placed third-party admin themes in /textpattern/themes/ so there is no real difference, except for the location.

Sure, but that doesn’t mean it can’t be improved.

OK, with TXP 4.6 there is an added complication, in that you can have a custom stylesheet or JS file inside admin themes folders.

Is it wrong to desire fewer complications?

Textpattern CMS support forum

#76 2016-06-14 10:28:19

Re: Feedback to: Textpattern CMS 4.6.0 beta released

Bloke wrote #299710:

#77 2016-06-14 12:12:18

Re: Feedback to: Textpattern CMS 4.6.0 beta released

philwareham wrote #299713:

#78 2016-06-14 12:19:00

Re: Feedback to: Textpattern CMS 4.6.0 beta released

Bloke wrote #299719:

#79 2016-06-14 12:36:31

Re: Feedback to: Textpattern CMS 4.6.0 beta released

phiw13 wrote #299721:

#80 2016-06-14 12:43:44

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#81 2016-06-14 12:53:59

Re: Feedback to: Textpattern CMS 4.6.0 beta released

Bloke wrote #299724:

#82 2016-06-14 13:01:48

Re: Feedback to: Textpattern CMS 4.6.0 beta released

philwareham wrote #299725:

#83 2016-06-14 13:23:52

Re: Feedback to: Textpattern CMS 4.6.0 beta released

Bloke wrote #299723:

#84 2016-06-15 11:55:52

Re: Feedback to: Textpattern CMS 4.6.0 beta released

Bloke wrote #299723:

#85 2016-06-15 12:35:04

Re: Feedback to: Textpattern CMS 4.6.0 beta released

phiw13 wrote #299749:

#86 2016-06-18 02:53:56

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#87 2016-06-18 05:50:58

Re: Feedback to: Textpattern CMS 4.6.0 beta released

gomedia wrote #299823:

#88 2016-06-18 06:02:23

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#89 2016-06-18 06:25:22

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#90 2016-06-18 07:04:52

Re: Feedback to: Textpattern CMS 4.6.0 beta released

phiw13 wrote #299828:

Board footer