That's what I thought and suggest for 1.6.3cmb wrote:easy for the language and config files
A different job.cmb wrote:it is extremely hard to do it for the stylesheets
That's what I thought and suggest for 1.6.3cmb wrote:easy for the language and config files
A different job.cmb wrote:it is extremely hard to do it for the stylesheets
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?Tata wrote:Then to have "start_defaults_chek" wich would check:
[Flowchart]
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).svasti wrote:but still we find things which could be or should be improved. Argh, there is no end to it
Therefore we have it on the roadmap.svasti wrote:cmb wrote:easy for the language and config files
That's what I thought and suggest for 1.6.3
Yes. However, we should consider that some kind of automatic update always will lead users to think that everything works automatically.svasti wrote:cmb wrote:it is extremely hard to do it for the stylesheets
A different job.
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.Holger wrote:Some thoughts how it could work:
[6 items]
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.Holger wrote:Garbage-collection of unused config- or language variables could easy made by comparing the arrays before writing the final configuration or language file.
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.cmb wrote:concerned regarding settings which have changed in the defaults
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:cmb wrote:default and custom stylesheets
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.
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.svasti wrote: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.
Yes.cmb wrote: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.
Good arguments .cmb wrote: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]).
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');
?>
Hmm, I can't remember... .cmb wrote:Regarding the custom stylesheets: didn't we have this discussion/suggestion before? I couldn't find it on the roadmap.
Is there another option - beside writig a complex parser?cmb wrote:Anyway, while I'm not against introducing default and custom stylesheets, I'm not sure that it will solve all the issues
That would be a real user-friendly solution IMO, even if I don't like another file per plugin too.cmb wrote:(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.
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.cmb wrote: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.
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.svasti wrote: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.
Hmm, isn't that the same ugly thing like now, announced in a dialog?svasti wrote: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.
At least that seems to be viable solution.Holger wrote: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.
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:Holger wrote:So why not just enhance the default.php files with an array of keys which are not subject to change by existing user-setting
Code: Select all
$plugin_cf['jquery']['_preserve']=array('version_core', 'version_ui'); // or:
$plugin_cf['jquery']['_preserve']="version_core,version_ui";
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.Holger wrote:Is there another option - beside writig a complex parser?cmb wrote:Anyway, while I'm not against introducing default and custom stylesheets, I'm not sure that it will solve all the issues
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.Holger wrote:Hmm, isn't that the same ugly thing like now, announced in a dialog?svasti wrote: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.
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.
And far worse things can happen: https://www.wordfence.com/blog/2016/11/ ... to-update/cmb wrote:And you may not even know, that your site has been broken!Holger wrote: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.
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.