[#14919] - remove new router feature
- Fixed in Code Base
- 27 Mar 2017
- Medium
- Build: staging
- # 14919
- Diff
- rdeutz:feature/remove_router
User tests: Successful: Unsuccessful:
Executed summery
Removed the new router feature for
- com_contact
- com_content
- com_newsfeed
- com_users
Testinstructions
- Install Joomla with Testdata
- Apply patch
- Test if menu links are still working
- Test if link other links still working
Expected result
Links should still work
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_contact com_content com_newsfeeds com_users Front End |
@brianteeman you are right, we have to
Are you going to do it here or shall i create a new pr for the strngs?
I see competence through and through. This PR breaks backwards compatibility to 3.6.5 and all previous versions. I mean, if you don't understand a feature and because of that want to remove it, then at least make sure that you don't remove pre-existing functionality.
I have tested this item
This change is not backwards compatible to 3.6.5 and prior.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/14919.
I see competence through and through
I assume you mean incompetence? http://www.dict.cc/englisch-deutsch/incompetence.html
Or perhaps...
http://dictionary.cambridge.org/dictionary/english/irony
I tried to use irony. Anyway, this also misses a big bunch of changes and by deleting what you deleted, all URLs will be broken for those components now.
@brianteeman Either you really remove all the code, then you have to remove the legacyrouter.php and restore the original routers (with the exact content from those legacyrouter.php files) and also restore all the other files that were changed because of this feature or you do what the PLT decided and just remove the GUI option. /me wonders why neither was done here.
Only the GUI options should be removed in 3.7. Like that the router team can then decide the path they want to go for version 3.8, rewrite it from scratch or modify the existing code. For 3.7 is see no reason to remove the code and introduce some potential instability.
Why we should ship code we don't use at all?
You're opening a Pandora's Box by asking that question, there is a lot of code shipped with core that isn't actually used by core (including the social library packages, OAuth clients, the base routing classes (without the new system available to users), data objects, half the database API...).
The intent is to improve upon the routing system in 3.8 based on Hannes' work. The least disruptive option right now is to simply hide the UI options.
As we did with the original sef_advanced code
| Labels |
Added:
?
?
|
||
| Category | Administration com_contact com_content com_newsfeeds com_users Front End | ⇒ | Administration com_contact com_content com_newsfeeds com_users |
I just only removed the UI, more changes can be discussed later. My problem with let the code in, is, if someone build something on this and we have to make bigger changes we need to makes sure we support the rules for < 3.7.0, for between 3.7.0 and 3.8.0 and that what we might come came up as new routing. This will make the job far more complicated
Anything that has to change in the library classes is already locked to B/C issues since they've been there since 3.3/3.4 timeframe. The actual component implementations aren't locked in that same way, with or without the config exposed in the UI. So I think we're somewhat safe for the moment.
wilsonge
- | Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-03-27 17:43:23 |
| Closed_By | ⇒ | wilsonge |
Dont we need to remove the new language strings as well?
On 27 March 2017 at 10:57, Robert Deutz notifications@github.com wrote:
--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/