[#10828] - [update sites rebuild/delete] Only for non core extensions. Solves #10826
- Fixed in Code Base
- 21 Jul 2016
- Medium
- Build: staging
- # 10828
- Diff
- andrepereiradasilva:patch-17
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success JTracker/HumanTestResults Human Test Results: 2 Successful 0 Failed. Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #10826 and #10857 (update sites part).
Summary of Changes
This PR changes updates sites rebuild process so only non core extensions can be deleted/rebuilt.
Also adds a error message on Rebuild when extension joomla plugin is disabled.
Testing Instructions
- Use joomla latest staging
- Confirm problems described in #10826 are solved
- Do a general test in update sites delete/rebuild process with several 3º party extensions with update servers (of several types: templates, frameworks, modules, plugins, components, etc)
- Disable Joomla Extension plugin
- Try to Rebuild and check the error message
- Enable Joomla Extension plugin and repeat step 5. no error
- Code review
Observations
Mantainers this hardcodes joomla, pkg_en-GB and com_joomlaupdate has core extensions with update servers.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Title |
|
||||||
| Title |
|
||||||
hum ... any ideas? use 802 as last id?
IDs are unreliable as a limiter. That's my only idea right now.
ok, maybe hardcode the core elements with update sites: joomla, pkg_en-GB and com_joomlaupdate, this way we don't use ids
| Title |
|
||||||
| Title |
|
||||||
| Category | ⇒ | Administration |
| Title |
|
||||||
| Title |
|
||||||
| Labels |
Added:
?
|
||
Made some improvements to, when rebuilding the update sites, check if the joomla extension plugin is enabled (see #10857).
Now it only allows to rebuild the update sites if the Joomla Extension Plugin is enabled, otherwise it retuns an error message indicating you have to enable it.
done
no volunteers for testing this one?
Tested with a language pack for which http was changed to https in the manifest. The http one is deleted after patch. Therefore success.
Are kept in the list 2 instances of
Joomla Core
Joomla Extension Directory
Joomla! Update Component Update Site
one with http and one with https.
Any reason to not take care of these? Impossible because they are locked?
Are kept in the list 2 instances of
Joomla Core
Joomla Extension Directory
Joomla! Update Component Update Siteone with http and one with https.
Any reason to not take care of these? Impossible because they are locked?
Why do you have one with http and other with https?
In joomla 3.6.x. They are all HTTPS (in DB and manifest file).
Anyway, any update site that matches this query will not be rebuilded and can't be deleted.
Why do you have one with http and other with https?
In joomla 3.6.x. They are all HTTPS (in DB and manifest file).
This is a legacy site, not a new install.
did you make a regular update, this is changed in update sqls?
Nope. Just by overwriting on my test site.
ok so that's the issue, is not related to this PR. So your test was a success
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10828.
I have tested this item
It works as it should do.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10828.
| Status | Pending | ⇒ | Ready to Commit |
| Labels | |||
| Labels |
Added:
?
|
||
roland-d
- | Milestone |
Added: |
||
wilsonge
- | Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-07-21 21:26:28 |
| Closed_By | ⇒ | wilsonge |
| Labels |
Removed:
?
|
||
If the database schema is valid, then only core extensions should have an ID of less than 10000. However, this is not always the case; I have seen issues (I forget where right now) related to a database where the auto increment value was not correctly set.