> I have just that, but a bit more sophisticated: I *extend *the class I
> want
> to override after giving the "old" class another name and extending from
> that class. In that way I can for instance easily override a single method
> and even still use the old (parent) method. I use it regularly to
> extend-override classes, not only from the platform, but even more often
> from 3PD-extensions. I now use it looking where the file is located in my
> override-folder, but planned to make an administrative interface with it
> too, so you can also override a class in the /administrator-folder if you
> want to use that in the site-side of the CMS. For at the moment you must
> look out not to override a class in the frontend if you use the same class
> in the backend (and the other way around).
> I simply use the "not a hack hack" plugin method as described in the
> Joomla! Programming Book page 182-185. But as I said: I read the "old"
> class, change the classname, include that old class with the new name, and
> then load the "overriden" class with the old name (extended from the old
> clas with new name). Works like a charm.
> Word of warning: there are extensions that use this system-plugin method
> too and that could give conflicts: who is the first one to be loaded. That
> is also why you sometimes see plugins with an ordering of say -30000
> (lowest numbers go first). There even seem to be agreements between some
> 3PD's who gets first... So just look out if those plugins are doing the
> same trick with the same classes as you want to override, for that won't
> work (class can only be loaded once).
> My thought is: if I just put it on the JED, you can use it as you want;
> but
> it is not necessary a core feature. Probably only a few developers who
> want
> to use this (and they could allready use the plugin-trick). BTW: in
> PrestaShop (an open source e-commerce application) every class can be
> overridden in your theme. That works nice (but not as good as my *extended
> override*, hehe).
> On Wednesday, 15 August 2012 20:54:57 UTC+2, Nick Savov wrote:
>> Hi everyone,
>> I'm thinking about hiring a trusted developer (it's beyond my
>> capabilities) to propose a feature patch for a more powerful overriding
>> system (in addition to what we have now). I wanted to first to run my
>> idea
>> by you in case it wasn't worth pursuing.
>> Joomla has a lot of great override abilities (template overrides,
>> alternative layout overrides, etc), however why don't we create an
>> override
>> folder where admins can insert files with the same same paths to
>> override
>> the originals? The platform would just have to process those files
>> first.
>> If an override is found, there's no need to process the file being
>> overridden.
>> For example, if you wanted to override the following file (to change the
>> Type attribute):
>> /libraries/joomla/document/html/renderer/head.php
>> You could just upload the override to:
>> overrides/libraries/joomla/document/html/renderer/head.php
>> without having to resort to all sorts of elaborate hacks.
>> It's a very simple concept and I think it would be relatively easy to
>> implement (for a capable developer). This wouldn't replace any of our
>> current override capabilities, but just add an additional way to
>> override.
>> The current capabilities, although great, have limitations that this
>> method would help resolve and would allow us to basically override
>> almost
>> every file easily.
> Having a standard approach to override any file -- without loading a
> system
> plugin -- would be ideal. One consideration for future releases is
> preparing for namespaces. That's something that adds a level of difficulty
> to overrides that we have yet to encounter with Joomla.
> On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren
> <herman.pee...@gmail.com>wrote:
>> Here is the way I change the classname (will change JFile into native
>> PHP):
>> // read the old class-deninition file
>> $oldfile = JFile::read($oldfile_path);
>> Before, I did an eval() on $oldfile (after removing <?php from the
>> beginning), but now I write the changed file in a cache-subfolder of my
>> overrides-folder and include_once that modified file. In that way I also
>> have a cache for the old files (which has to be cleaned up if the old
>> file
>> is updated. Still working on automating that; thought on an
>> onAfterUpdate-plugin).
> There is no need to load another autoloader in place of the standard ones.
> Autoloaders cascade. It is simply a matter of loading another path for
> the J prefix and those paths will be searched first.
> Here are some trivial solutions to the problem, if all you want to do is
> load alternative class definitions:
> 1. Write a system plugin that calls JLoader::registerPrefix to register a
> new path for the 'J' prefix. (2.5+)
> 2. Call spl_autoload_register to register a new autoloader to load
> classes.
> If you use the prepend option it will use the autoloader you specify
> first
> which will take precedence over the system one. (2.5+)
> 3. Write a system plugin that loads class definitions for the class you
> want to override (1.5+ - most classes, 2.5 probably all classes)
> 4. The CMS could choose to load a specific path as an alternative prefix
> in
> future versions (i.e. do option 1 out of the box).
> You can also reference
> http://community.joomla.org/blogs/community/521-did-you-know-override... > for
> a discussion on this topic for Joomla 1.5, which for the most part also
> applies to Joomla 2.5.
> Ian
> On Wednesday, 15 August 2012 20:32:15 UTC-4, Mark Dexter wrote:
>> I would think that the autoloader opens up some possibilities for
>> creating simple overrides. For example, how hard would it be to load a
>> custom autoloader in place of the standard one? In that case, you
>> could have that one look first to an override folder. If that works,
>> perhaps make the standard autoloader look first to an override folder?
>> Just thinking out loud. Mark
>> On Wed, Aug 15, 2012 at 5:29 PM, Amy Stephen
>> <amyst...@gmail.com<javascript:>>
>> wrote:
>> > I've seen others do that eval approach. Interesting how many ways
>> people
>> > have devised to come up with overrides for Joomla.
>> > Having a standard approach to override any file -- without loading a
>> system
>> > plugin -- would be ideal. One consideration for future releases is
>> preparing
>> > for namespaces. That's something that adds a level of difficulty to
>> > overrides that we have yet to encounter with Joomla.
>> > On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren
>> <herman...@gmail.com<javascript:>>
>> > wrote:
>> >> Here is the way I change the classname (will change JFile into native
>> >> PHP):
>> >> // read the old class-deninition file
>> >> $oldfile = JFile::read($oldfile_path);
>> >> // change the classname
>> >> $oldfile = str_replace($classname,
>> >> $classname.'_overridebase', $oldfile);
>> >> Before, I did an eval() on $oldfile (after removing <?php from the
>> >> beginning), but now I write the changed file in a cache-subfolder of
>> my
>> >> overrides-folder and include_once that modified file. In that way I
>> also
>> >> have a cache for the old files (which has to be cleaned up if the old
>> file
>> >> is updated. Still working on automating that; thought on an
>> >> onAfterUpdate-plugin).
Wow, a lot of people contributed to this discussion. Instead of going
through this individually, I'd like to say thank you to everyone for your
help! I've read each of your comments and they helped a ton!
At this point, I'd like to move forward with an implementation since this
would need to get in before Joomla 3 beta. If anyone would like to help,
I would greatly appreciate your help!
Roberto and J lio, I've add you to Skype. If you have some time, let's
chat :)
> I'm thinking about hiring a trusted developer (it's beyond my
> capabilities)
> to propose a feature patch for a more powerful overriding system (in
> addition to what we have now). I wanted to first to run my idea by you in
> case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides,
> alternative layout overrides, etc), however why don't we create an
> override
> folder where admins can insert files with the same same paths to override
> the originals? The platform would just have to process those files first.
> If an override is found, there's no need to process the file being
> overridden.
> For example, if you wanted to override the following file (to change the
> Type attribute):
> /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to:
> overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to
> implement (for a capable developer). This wouldn't replace any of our
> current override capabilities, but just add an additional way to override.
> The current capabilities, although great, have limitations that this
> method would help resolve and would allow us to basically override almost
> every file easily.
This is what I do in order to override system classes. I wrote up a blog post explaining everything more clearly than what the code provides, but by blog got nuked and I'm still working on getting that back up. In the mean time:
On Sat, Sep 1, 2012 at 10:08 AM, dilbert4life <dilbert4l...@gmail.com>wrote:
> This is what I do in order to override system classes. I wrote up a blog
> post explaining everything more clearly than what the code provides, but by
> blog got nuked and I'm still working on getting that back up. In the mean
> time:
> I'm very enamored of the proposal that Júlio put forth. It is mostly an
> extension of the template overrides that are currently allowed but
> expanding it out to encompass all code files for an extension. It's great
> because I can't tell you the number of times that a client has wanted to
> add just one parameter to an article that could be accessed in the layout.
> Using this approach I could simply override the XML form file, and edit
> the
> field entries in the params fields. I whole heartedly endorse this plan of
> action; it is magical in its simplicity.
>> I'm very enamored of the proposal that Júlio put forth. It is mostly an
>> extension of the template overrides that are currently allowed but
>> expanding it out to encompass all code files for an extension. It's great
>> because I can't tell you the number of times that a client has wanted to
>> add just one parameter to an article that could be accessed in the layout.
>> Using this approach I could simply override the XML form file, and edit
>> the
>> field entries in the params fields. I whole heartedly endorse this plan of
>> action; it is magical in its simplicity.
>>> I'm very enamored of the proposal that J lio put forth. It is mostly an
>>> extension of the template overrides that are currently allowed but
>>> expanding it out to encompass all code files for an extension. It's
>>> great
>>> because I can't tell you the number of times that a client has wanted
>>> to
>>> add just one parameter to an article that could be accessed in the
>>> layout.
>>> Using this approach I could simply override the XML form file, and edit
>>> the
>>> field entries in the params fields. I whole heartedly endorse this plan
>>> of
>>> action; it is magical in its simplicity.
