Feedback to: Textpattern CMS 4.6.0 beta released

philwareham · 2016-06-12 20:23:49

@guguser

I like that idea, it could replace the custom snippets I currently have (I could put them into this file but commented out, for people to use or not use depending on their preference). Please open an issue at the Textpattern repo and I’ll take ownership.

phiw13 · 2016-06-13 02:49:43

@guguser

Sounds like a good idea. I wonder though, what happens when afterwards you install a third party theme that also offers that option? There could be possible clashes. Or would it be preferable for the third party theme to make the link to a distinct stylesheet (with prefix)? On the flip side, if you care enough to massage a user stylesheet like that, it is probably a no brainer to update the user stylesheet for the third party theme (I’ve tentatively included that option in my Sandspaces theme).

GugUser · 2016-06-13 03:09:17

@phiw13

I think the third party theme should include a “third_party_theme.php” which includes by default the same lines:

if (defined('additional_user_css')) {
    $out[] = '<link rel="stylesheet" href="admin-themes/additional_user_css.css">';
}

The user is responsible for what he does in the “additional_user_css.css”. This file is for people who know what they are doing. The advantage is, the user can switch from one to the other theme and things like (is only an example)…

#custom_field_group input[type="text"], .glz_custom_field input[type="text"] {
	width: 100% !important;
}

… remain as they are.

I tested the proposal with the two Hive themes.

Last edited by GugUser (2016-06-13 03:10:59)

jpdupont · 2016-06-13 07:48:54

I’ts a popup message when eg I try to change the category of articles :

Êtes-vous certain ?

See the   displayed in the french translation.

philwareham · 2016-06-13 10:23:53

@GugUser

OK, I have reworked the custom CSS for the admin-themes as suggested, see this commit. Grab the latest code from GitHub to use (or wait for beta2 which should probably be made available this week).

The activator for the file is to add this to your config.php:

define('admin_custom_css', true);

Then, within the theme’s assets -> css directory you will find a custom.css file which you can amend to your heart’s content – I’ve also moved all the old custom CSS toggles (which were previously multiple files) to that file, which you can uncomment to activate (or delete if you want to).

Let mw know if you have any problems with it. Maybe once settled in, someone would like to post a forum topic somewhere so various handy customisations can be shared between users?

The custom.css is specific to the theme, so for other admin-theme authors to support it, they will need to add a custom.css file to their own admin theme’s directory.

uli · 2016-06-13 13:34:52

phiw13 wrote #299663:

I wonder though, what happens when afterwards you install a third party theme that also offers that option? There could be possible clashes.

phiw13, that’s only a small change in the rel value: Phil already has a folder called custom inside each theme’s css directory.

After seeing this proposal––great idea, BTW, Guguser!––I instantly tried a JS variant.

if (defined('custom_admin_js')) {
	$out[] = '<script src="'.$this->url.'assets/js/custom/custom_admin_js.js">';
}

define('custom_admin_js', true);

I hope we’ll get that likewise. We still need hacking textpattern.js (or install a two plugins combo to get custom JS working that survives updates), e.g. if necessary on the images page. (My example needs a custom folder inside the themes JS directory to match the CSS directory structure.)

Sorry, still no GitHub account.

Edited to add quote.

Last edited by uli (2016-06-13 13:38:02)

uli · 2016-06-13 13:46:26

Ah, OK Phil, you’ve changed the directory structure. Didn’t notice there were more posts below phiw13’s on a new page.

phiw13 · 2016-06-13 13:47:15

uli wrote #299672:

phiw13, that’s only a small change in the rel value: Phil already has a folder called custom inside each theme’s css directory.

Hmm, OK the way Phil implemented it, the custom stylesheet resides in the admin-themes/hive folder. The original idea however was pointing to a location outside of the specific theme folder (at the root of admin-themes. That has one big benefit, in that there is absolutely no risk that the stylesheet will be overridden/destroyed during an update (in the case of Hive theme it would ship with a custom stylesheet included).

philwareham · 2016-06-13 14:07:43

phiw13 wrote #299674:

Hmm, OK the way Phil implemented it…

I’m open to suggestions here. The way I saw it, many customisations would be targeted at a specific theme directly, so having the custom.css contained with that theme made sense. No?

Also, not sure if an extra folder in admin-themes directory causes the system to think there is an additional theme available or not? If so, then some code will need to be added to the core to basically ignore that folder (which I am not able to code myself).

GugUser · 2016-06-13 14:22:49

philwareham wrote #299667:

@GugUser

OK, I have reworked the custom CSS for the admin-themes as suggested, see this commit.

(…)

The custom.css is specific to the theme, so for other admin-theme authors to support it, they will need to add a custom.css file to their own admin theme’s directory.

Many thanks for the quick processing of my idea. It is certainly easier to manage all the old custom CSS toggles in one file.

However, I would prefer if the custom.css were located outside the theme folders, so it would be themes independent. Part of my idea was that the custom.css is easily accessible, so it will be not forget during an update, for example, similar to config.php. At the moment it is very nested.

Nevertheless, it is much better than before. Thanks.

Bloke · 2016-06-13 15:03:26

philwareham wrote #299676:

an extra folder in admin-themes directory causes the system to think there is an additional theme available

This is correct. Any folder in there is assumed to conform to a theme package, so a rogue folder which deviates from the theme structure will (probably spectacularly) break stuff.

Unless, as Phil says, we somehow put an exception in core, this is sadly a non-starter.

Bloke · 2016-06-13 15:09:23

GugUser wrote #299677:

I would prefer if the custom.css were located outside the theme folders, so it would be themes independent.

Implementing custom.whatever files per theme will work fine, but the core must not use it. So if this system were put in place, Phil would not be able to use custom.css (or Uli’s custom.js suggestion) for core-shipped themes. Otherwise, as you say, the files’ll get nobbled on updates.

That does mean that core themes would use a different customisation mechanism to any user-defined stuff, which means people packaging up mods for others to use, might need to add instructions to say “turn off a, b and c in the core Hive theme’s hive-custom.css file” (or words to that effect). Not ideal.

Textpattern CMS

Textpattern CMS support forum

#49 2016-06-12 20:23:49

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#50 2016-06-13 02:49:43

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#51 2016-06-13 03:09:17

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#52 2016-06-13 07:48:54

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#53 2016-06-13 10:23:53

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#54 2016-06-13 13:34:52

Re: Feedback to: Textpattern CMS 4.6.0 beta released

phiw13 wrote #299663:

#55 2016-06-13 13:46:26

Re: Feedback to: Textpattern CMS 4.6.0 beta released

#56 2016-06-13 13:47:15

Re: Feedback to: Textpattern CMS 4.6.0 beta released

uli wrote #299672:

#57 2016-06-13 14:07:43

Re: Feedback to: Textpattern CMS 4.6.0 beta released

phiw13 wrote #299674:

#58 2016-06-13 14:22:49

Re: Feedback to: Textpattern CMS 4.6.0 beta released

philwareham wrote #299667:

#59 2016-06-13 15:03:26

Re: Feedback to: Textpattern CMS 4.6.0 beta released

philwareham wrote #299676:

#60 2016-06-13 15:09:23

Re: Feedback to: Textpattern CMS 4.6.0 beta released

GugUser wrote #299677:

Board footer