Alert to marketplace developers - another 5.7.4 breaking change
Permalink 2 users found helpful
Not as serious at the autoloader change, but this may affect some addons in the marketplace.
If an addon used the full address of the URL class:
The class has moved and the above will no longer work.
If an addon used the shortcut to the URL class:
The addon will not have any problems because the shortcut now points to the new address.
If an addon used the full address of the URL class:
use \Concrete\Core\Routing\URL;The class has moved and the above will no longer work.
If an addon used the shortcut to the URL class:
use URL;The addon will not have any problems because the shortcut now points to the new address.
Good to know.
Lacking any documentation / instruction / context up until your message, I always thought that the alias' were for the lazy, and were most useful for those who wanted to trade precision for conciseness (there's got to be more than one Url class across all namespaces).
Lacking any documentation / instruction / context up until your message, I always thought that the alias' were for the lazy, and were most useful for those who wanted to trade precision for conciseness (there's got to be more than one Url class across all namespaces).
@jshannon
No. Aliases are to reduce the verboseness introduced by namespaces which ironically undermines the primary reason for namespaces. It's a kludge really but I think you may find that the following are equivalent
5.7.x
5.6.x
No. Aliases are to reduce the verboseness introduced by namespaces which ironically undermines the primary reason for namespaces. It's a kludge really but I think you may find that the following are equivalent
5.7.x
use URL; $URL= new \URL();
5.6.x
$URL = Loader::helper(‘url’);
Before the days of the web and php and even before taking pics of fishes, I worked on a variety of defence and other high integrity projects where any use of aliases was explicitly prohibited. Knowing exactly what was being used and exactly where it came from was considered a key factor in creating reliable and maintainable code.
Honestly I'm not sure what the reasoning is behind putting the classes at the root namespace or taking that approach as opposed to running everything through some namspaced facade or Loader:: type class. At this point I've just decided that's a concrete5 convention (which was honestly probably borrowed from somewhere else) and I'll embrace it and leverage it in my concrete5 coding if it means I get the benefit of my code not breaking when classes get switched around, and I can easily extend any one of those classes or replace it by setting my own config override values.
https://github.com/concrete5/concrete5-5.7.0/blob/develop/web/concre... (see the 'aliases' and 'facades' arrays)
The intent of these isn't to make life more difficult (admittedly it's not something most people think/know about until after the fact), but rather to allow these classes to be extended/overwritten/switched out as needed as new requirements, functionality, etc become known.
John you're absolutely right though, those who used the fully qualified namespace will have stuff broken in this case because the location of that class changed. I just wanted to add a little bit of context as to how it could be avoided so that we can hopefully mitigate some of these kinds of issues in the future.