User tests: Successful: Unsuccessful:
This PR intends to normalize onfig global default options in com_content.
The method used was:
None.
changed:
added:
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_content SQL Installation Postgresql MS SQL |
Labels |
Added:
?
|
ok. let's hope this gets tests so we don't get conflict in any change of the xml
also there A LOT of components this is needed
Keep in mind that the default values in the XML have to match the default values used in PHP code for B/C reasons. If they are different, adjust the XML one but never adjust the PHP one or you change behavior (you can do that with 4.0).
The SQL ones actually are allowed to be different. They only apply for new installations and thus we have no B/C issues here.
ok so we have $params->get('save_history', 0)
(changed to 1) this means the default save_history needs to be 0
in the config.xml?
Found also:
$this->params->get('show_category_title', 1)
(changed to 0)$this->params->get('show_description', 1)
(changed to 0)$this->params->get('show_cat_num_articles', 1)
(changed to 0)So @Bakual what do you propose? The opposite? Use the config default and change the sql with those values?
ok so we have $params->get('save_history', 0) (changed to 1) this means the default save_history needs to be 0 in the config.xml?
That needs to stay as 0 in the XML. It's this way since we didn't want to enable versioning for updating users when it was introduced, but for new installs we enable it by default.
The others seems to be inconsistent currently even in code. I don't know the reason there (if there even is one). You need to take the current PHP behaviour and make the XML fit it. Reason for that is that there may be cases that there is no saved value for the param and you don't want to change the behaviour magically if the user just opens and saves the options without changing anything.
As said, the SQL files don't have to match the XML and PHP ones. Just the XML and PHP have to match and there the PHP takes precende and the XML has to follow it. There are valid reasons for the SQL one to be different.
For the "Use Global" feature, it's just important that there is a saved value (the SQL one). It doesn't matter at all which value that is. Just take a sensible default value.
ok i guess i will have to review this again.
ok reviewed. should be fine now. also updated PR description
Title |
|
Title |
|
@andrepereiradasilva Could you fix the merge conflicts so we can test this? Thanks.
If this Issue get no Response, it will be closed at 22th September 2018.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-09-23 05:17:08 |
Closed_By | ⇒ | franz-wohlkoenig |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/12962
This has been closed due to lack of response to the requests above – it can always be reopened.
Thank you so much for doing this!!!
I said I would do it but I'e been massively bogged down with some client
work. It sounds like your methodology is very similar to the one that I had
planned although I suspect yours is better
On 21 November 2016 at 19:41, andrepereiradasilva notifications@github.com
wrote:
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/