Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.6.0 Alpha1] fix language access inconsistency #10646

Closed
wants to merge 3 commits into from
Closed

[3.6.0 Alpha1] fix language access inconsistency #10646

wants to merge 3 commits into from

Conversation

shur
Copy link
Contributor

@shur shur commented May 27, 2016

One more inconsistency between updated Joomla site and freshly installed Joomla site.

Testing Instructions

  1. Install Joomla 3.2.0 or earlier version.
  2. Update to Joomla 3.6.0
  3. Go to Extensions > Languages > Content Languages
Expected result

We must see Access: Public (as in freshly installed Joomla 3.6.0).
languages-english-access-j360-clean-install

Actual result

But we see Access: not set
languages-english-access-j320-to-j360

This PR fixes this inconsistency for English language access field.
Exploring the problem I discovered when this inconsistency was made #2714

@brianteeman
Copy link
Contributor

Won't this mean that if a language has been set to anything other than public it will be changed on an update.

@shur
Copy link
Contributor Author

shur commented May 27, 2016

I have already considered that this access field can be changed. That's why I made a restriction:
ANDaccess= 0 to apply changes only in case when access is not set.

@andrepereiradasilva
Copy link
Contributor

andrepereiradasilva commented May 27, 2016

i think it would be better to have that change in new sql files.

Also since a user can easily change the language title, wouldn't be better to change all languages that have access level of '0'? (there is no access level with 0 id)

UPDATE `#__languages` SET `access` = 1 WHERE `access` = 0;

Even then, a issue that remains is if the user somehow deleted the view access level with the id 1 (Public). Probably that's a really wild scenario since for deleting the Public access level you need to have no content with Public access level.

@Bakual
Copy link
Contributor

Bakual commented May 27, 2016

Isn't that a known issue for updated sites and you actually should have a post-install message about it?

Setting it to 1 isn't the correct thing to do. The access level with the id 1 can be anything. It just happens to be "public" on most sites because it's preinstalled this way, but you can change that.
That's why we decided back then to not have an update SQL but a postinstall message.

@Bakual
Copy link
Contributor

Bakual commented May 27, 2016

@andrepereiradasilva
Copy link
Contributor

yeah, @Bakual is right IMO.

@brianteeman
Copy link
Contributor

brianteeman commented May 27, 2016 via email

@Bakual
Copy link
Contributor

Bakual commented May 27, 2016

I'm closing this as a known issue which will not be fixed.
See also https://docs.joomla.org/J3.x:Infinite_error_loop_on_multilanguage_sites

@Bakual Bakual closed this May 27, 2016
@infograf768
Copy link
Member

also, we prvented an error in the languagefilter. see #6194

@shur shur deleted the patch-14 branch November 7, 2016 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants