default language files for all languages

[svasti]

I find this is kind of frustrating: Now we have such a nice new version 1.6.2, which is of course the best ever, but still we find things which could be or should be improved. Argh, there is no end to it

easy for the language and config files

That's what I thought and suggest for 1.6.3

it is extremely hard to do it for the stylesheets

A different job.

[cmb]

Then to have "start_defaults_chek" wich would check:
[Flowchart]

Basically I agree. However, that is much more demanding than svasti's suggestion. What about if we put that on the roadmap for XH 1.7?

but still we find things which could be or should be improved. Argh, there is no end to it

That's inevitable, in my opinion, when developing software: there are always things that can be improved. And if there is no improvement at any point, the software will slowly fade away. A notable exception is TeX which is slowly approaching completion, but I assume that it is used on for a small fraction of typesetting applications (Word & Co. have much more widespread impact).

easy for the language and config files

That's what I thought and suggest for 1.6.3

Therefore we have it on the roadmap.

it is extremely hard to do it for the stylesheets

A different job.

Yes. However, we should consider that some kind of automatic update always will lead users to think that everything works automatically.

[Holger]

Hot topic .

As I wrote before, I would be fine with a "simple" and "save" update by the admin.
And I think implementation would not be so hard. Some thoughts how it could work:

1. Every update/upgrade should come with default.php and defaultconfig.php.
2. The package should not contain $sl.php and config.php files.
3. Now the core has to check, if the above files are available and include them as defaults.
4. After that, include existing config / language files - to catch the settings the user changed before (if those files exist).
5. Save or create the "real" config and language files and delete the default-files.
6. If files/folders are not writable, throw a warning message and drop step [5.]

Garbage-collection of unused config- or language variables could easy made by comparing the arrays before writing the final configuration or language file.
Ok, this solution requires for every include one more if condition, to check if a default...php exists.
So if you're in doubt about performance issues, maybe the process to build the final files could be started by the admin or some other condition.
But then it's possible, that some code breaks because important setting are missing.

IMO this way, updates could become really painless.
And if it's a precondition that config and language-folders are writeable, also the installation-package of a fresh install could come only with default...php files.
In the best case, just overwriting all files and folders with a full-package could result in a working and up to date installation (at least with most plugins seems that possible).

And about the stylesheets: for sure that's a hard to solve issue. And some (almost older) plugins have really bad styles included (special fonts, font-size, background-colors or containers with fixed-width). Rewriting the styles on every update is really frustrating.
I've started to put all changed style-definitions in a special css-file and leave the original plugin-styles untouched. So I only have to touch my custom-css-file, when something goes wrong with a new version of a plugin-stylesheet or when I have to make a clean-up because I've removed a plugin.
The only problem is the missing feature to edit this "custom-styles" online and to include it as last stylesheet with help of the core.
By now you must reference the file in the template.
That's the way how css-frameworks handles user-defined additions. YAML for example leaves all basic core-styles for easier updating untouched and uses a basemod.css to overwrite and extend the definitions by the user.
With a little help by the core (load the styles after all others), creating a similar working plugin could be easy developed.

I know, some issues are still open. But we should think about it because in my opinion the above mentioned suggestions seems easy to develop and fits fine into existing processes.
So the chance to break something is really small.

Holger

[cmb]

Some thoughts how it could work:
[6 items]

Steps 1-4 are basically as it works now, if I understand you correctly. Steps 5+6 would be an improvement, though, as only checking for the existence of default.php is more efficient than including the file on each request.

Garbage-collection of unused config- or language variables could easy made by comparing the arrays before writing the final configuration or language file.

ACK. However, I am still somewhat concerned regarding settings which have changed in the defaults. These would be ignored. Consider jQuery4CMSimple's settings regarding the jQuery(UI) versions to use. A user might make several updates without changing these settings, what might break some functionality on some browsers. Then he does an update, but the configured version isn't there any more.

The same problem could happen for language strings, which may have been updated for a good reason (better explanation, or perhaps even a change of the functionality [e.g. for the help texts]).

Regarding the custom stylesheets: didn't we have this discussion/suggestion before? I couldn't find it on the roadmap.

Anyway, while I'm not against introducing default and custom stylesheets, I'm not sure that it will solve all the issues (and I'm a bit concerned, to check for yet another file per plugin). If we do so, we may consider offering a single page where the default stylesheet can be viewed (read-only) and the custom stylesheet can be modified. Having only a single custom stylesheet for all plugins and perhaps to overwrite core.css is of course another option--not sure, if I'd prefer that, though.

[svasti]

concerned regarding settings which have changed in the defaults

If the $sl contains only changed settings, and the program would first read the default language file and then the $sl, the default can be changed.

default and custom stylesheets

This could be much more difficult. Maybe a user made some changes to a plugin stylesheet, which would not work properly with the new version of that plugin. What about an updating dialogue as:

Your stylesheet has been replaced. If you had made custom changes, <here> you can compare your old stylesheet to the new one and copy that part of your changes which you still think necessary.

[Holger]

If the $sl contains only changed settings, and the program would first read the default language file and then the $sl, the default can be changed.

That's how it works now, if I'm right. But Christoph has good arguments to not overwrite the defaults sometimes, as he wrote above.

Steps 1-4 are basically as it works now, if I understand you correctly. Steps 5+6 would be an improvement, though, as only checking for the existence of default.php is more efficient than including the file on each request.

Yes.

However, I am still somewhat concerned regarding settings which have changed in the defaults. These would be ignored. Consider jQuery4CMSimple's settings regarding the jQuery(UI) versions to use. A user might make several updates without changing these settings, what might break some functionality on some browsers. Then he does an update, but the configured version isn't there any more.

The same problem could happen for language strings, which may have been updated for a good reason (better explanation, or perhaps even a change of the functionality [e.g. for the help texts]).

Good arguments .

So if I'm right we agree that we have (if a defaultxxx.php exists) to
- compare the defaults with the existing array-keys to remove the "garbage",
- take over user-changed settings
- but sometimes overwrite user-defined settings for good reasons.

So why not just enhance the default.php files with an array of keys which are not subject to change by existing user-setting. IMO that's not a so common case but for sure sometimes it's a must be.
For the jQuery example, a defaultconfig.php could look like sth. below:

Code: Select all

<?php
    $plugin_cf['jquery']['version_core']="1.11.1";
    $plugin_cf['jquery']['version_ui']="1.10.4";
    $plugin_cf['jquery']['version_migrate']="jquery-migrate-1.2.1.min.js";
    $plugin_cf['jquery']['load_migrate']="true";
    $plugin_cf['jquery']['autoload']="";

    $jquery_cf_preserve = array('version_core', 'version_ui');
?>

So while comparing the two arrays every variable with a key contained in $pluginname_cf_preserve keeps the default values, not those from the existing configuration / language.

Regarding the custom stylesheets: didn't we have this discussion/suggestion before? I couldn't find it on the roadmap.

Hmm, I can't remember... .

Anyway, while I'm not against introducing default and custom stylesheets, I'm not sure that it will solve all the issues

Is there another option - beside writig a complex parser?

(and I'm a bit concerned, to check for yet another file per plugin). If we do so, we may consider offering a single page where the default stylesheet can be viewed (read-only) and the custom stylesheet can be modified.

That would be a real user-friendly solution IMO, even if I don't like another file per plugin too.

Having only a single custom stylesheet for all plugins and perhaps to overwrite core.css is of course another option--not sure, if I'd prefer that, though.

For sure that's not much comfortable but it's just one more request and - beside this - by now I could not find another option / solution.

This could be much more difficult. Maybe a user made some changes to a plugin stylesheet, which would not work properly with the new version of that plugin.

Of course. But the plugin developer should take a bit care on that while coding his new version. And of course could a new version require new changes by the user. But often there might be updates where not so much has changed that the userdefined styles break the whole output.
So a way to keep the customised styles seems to me much better than redoing all changes on every update again (or to keep the outdated stylesheet complete, which increases the chance that something breaks a lot).

What about an updating dialogue as:

Your stylesheet has been replaced. If you had made custom changes, <here> you can compare your old stylesheet to the new one and copy that part of your changes which you still think necessary.

Hmm, isn't that the same ugly thing like now, announced in a dialog?
If I made changes in the original plugin-css, I have to compare the files and redo the changes on every update.
Or is the dialogue just meant as a warning for the user if a custom css exists? That might be useful.
But I think that if one made changes in a custom css, he knows that he has to check his code if something goes wrong with the styles.

[cmb]

So if I'm right we agree that we have (if a defaultxxx.php exists) to
- compare the defaults with the existing array-keys to remove the "garbage",
- take over user-changed settings
- but sometimes overwrite user-defined settings for good reasons.

At least that seems to be viable solution.

So why not just enhance the default.php files with an array of keys which are not subject to change by existing user-setting

If we're adding another variable to the files, we'd have to rewrite the current way of reading these files (keyword: XH_includeVar()), but of course that is an option. An alternative would be to use a reserved index of the usual variable, say:

Code: Select all

$plugin_cf['jquery']['_preserve']=array('version_core', 'version_ui'); // or:
$plugin_cf['jquery']['_preserve']="version_core,version_ui";

However, in this case we would have to treat this element specially, what might not be so clean.

Anyway, while I'm not against introducing default and custom stylesheets, I'm not sure that it will solve all the issues

Is there another option - beside writig a complex parser?

I was referring to changes of the selectors, as was pointed out by svasti in the meantime. But you've already made the point, that a plugin developer should try to avoid such changes, as far as possible.

Writing our own stylesheet parser is most likely not an option; there are, however, several CSS parsers available for PHP (I have no experience with any of them, though).

What about an updating dialogue as:
Your stylesheet has been replaced. If you had made custom changes, <here> you can compare your old stylesheet to the new one and copy that part of your changes which you still think necessary.

Hmm, isn't that the same ugly thing like now, announced in a dialog?
If I made changes in the original plugin-css, I have to compare the files and redo the changes on every update.
Or is the dialogue just meant as a warning for the user if a custom css exists? That might be useful.

Well, we might consider showing a real diff when the user clicks the <here> link. Depending on the quality of the diff (using a stylesheet parser or a normalizer/formatter for it might be beneficial) that could be really useful.

[cmb]

Look at the "painless" Worpress auto-update, LOL...

Personally I would not trust such a update-feature under all circumstances. It could break everything with a small mistake and you're not aware what exactly happened.

And you may not even know, that your site has been broken!

Furthermore WP's update requires all files and folders to be writable (or at least owned by the PHP user, so the files can be chmod'ed if necessary). It seems to me that this is likely to increase the impact of potential vulnerabilities.

And far worse things can happen: https://www.wordfence.com/blog/2016/11/ ... to-update/