Overriding Joomla! 1.6 Framework Classes

Many know me to be a big fan of the Drupal community. I like how they collaborate around development. This community culture has been the reason behind a rich array of highly interchangeable Modules that can be used in different ways for different site building needs.

Often, when Joomla! and Drupal are compared, it is said that Joomla! is for newbies or hobbyists and Drupal, on the other hand, is said to be the development platform of choice for robust applications when you need customize, high-end solutions.

Not to take anything away from Drupal, but Joomla! is an extremely flexible development environment. We need to do a better job of sharing clever approaches and discussing the advantages of developing in Joomla!.

With the Molajo project, we want to make changes to the ACL environment, a few changes to JForm and JHTML fields, and implement a system-wide Copy/Move Facility for all Joomla! Managers. As is our policy, all core improvements are submitted to the project as patches. Unfortunately, these changes have not been accepted, so we find ourselves in a situation many developers find themselves in: Do you go without these features? Hack the core? Or, can you override those classes and functions preferred differently?

Our goal is never to hack the core but rather to force ourselves to find other ways of bending Joomla! to our will. So, after much exploration, I want to share some of the methods that can be used to override Joomla! Core Classes .

This is an easy-to-review Joomla! 1.6 System Plugin called Override. It is a learning Extension, not something for non-developers. Take a close look at the override.php file. It is well documented and can be used to explain methods that you might consider as you are developing.

Some of these methods need to be used with caution and only in certain circumstances. Since we are providing a distribution of Joomla! 1.6 we need to have tighter control of the overall application.

As we move forward with Joomla! 1.6, the more we collaborate as a developer community, the more we will agree upon framework changes that we can prove with community use and offer to the project for core consideration. We should also begin considering integration standards and practices that improve integration with our extensions.

Let me know what you think of the plugin and please share other ways that you extend and override and otherwise force Joomla! to behave, exactly as you wish.

Tags: Joomla! 1.6

Comment by Denis Dulici on January 13, 2011 at 3:08pm: Amy, we can apply it on 1.5 too except defines.php

Comment by Marius van Rijnsoever on January 14, 2011 at 8:29pm: This is a clever way of loading modified joomla core files :)

Its hard to define a "core hack". With your override you load a modified core file, which is in fact the same result as overriding the physical file in the joomla library directory. The only difference is the location of the modified joomla library.

My suggestion would be to just directly apply the changes to the joomla core files. That will also mean it is easier to merge from the joomla branch into the Molajo branch (as the location of the file is the same)

Thanks again for your hard work, Marius

Comment by Marius van Rijnsoever on January 15, 2011 at 2:07am: Another question for you Amy. Are there any database changes for Molajo?

If not then upgrading a Joomla 1.6 site to a Molajo site would be as easy as unzip'ing a molajo package. Thanks, Marius

Comment by Michael Babker on January 15, 2011 at 6:09pm: RE: My suggestion would be to just directly apply the changes to the joomla core files. That will also mean it is easier to merge from the joomla branch into the Molajo branch (as the location of the file is the same)

Early in the SVN establishment, we ran into a lot of issues with conflicts by merging in the Joomla! trunk. This was most critically seen in the installation application as we had modified the core installation and sample data SQL's. Therefore, we decided to truly hack the installation application to add a second core installation SQL to process additional database entries and using a feature added during beta, we added the option for a Molajo sample data while leaving the core's sample data. I think the approach that we're taking is the best route to avoid conflicts and push the framework to the limits as far as just how extensable it is.

Regarding database changes, no, there are not any changes to the core table structure. In the second installation file I previously mentioned, we drop the data from seven tables and repopulate it to match what we're providing. Our true changes include removing the core changes in favor of the Construct Framework for the front end and Minima for the admin side, changing the update sites to pull for Molajo vice Joomla!, and adding a few extensions to the core installation.

You could do an SVN checkout of the Molajo trunk today and it would be Joomla! 1.6 with a few additional options, nothing more right now.

Comment by Jeremy Wilken on February 19, 2011 at 9:49pm: I bookmarked this for the time I expected to come, and it did, and this post most certainly gave me the quick direction I needed to override a class (protected property that cannot be accessed like before). Thanks so much!

Comment by Klas on February 20, 2011 at 6:22pm: you can as well extend a class to get to the protected property

Comment by Erik Roznbeker on May 27, 2011 at 7:39am: This plugin is great example. Only thing I can't figure out is how to override database class.

Comment by Amy Stephen on May 27, 2011 at 6:18pm: Interestingly, I had problems with that very class this past week. I found another way to solve my problem so I didn't sort it out. I wondered if loading the database driver needed, first, might do the trick. In the getInstance method - you can see that it's using the current directory to find the class. Maybe if you register it first, then move it, it might work? If you figure it out and think about it, let me know. Thanks!

Comment by Klas on May 28, 2011 at 12:55pm: For database or any class that is a mixin (also called method overloading, another example is cache) you also need to override some children classes (also called drivers - e.g. mysql or mysqli in database) as most methods are loaded from those classes, not from the base class. Actually, all you need to override is that children class as parent methods are only used if they are not defined in child.

Comment by Erik Roznbeker on May 29, 2011 at 1:47am: Problem is that all database classes are loaded before any plugin so JLoader::register() doesn't work in this case. Best (but not good) solution I found is to create new database connector (e.g. 'mysqlix.php', class JDatabaseMySQLix) and to set $dbtype = 'mysqlix'; in configuration.php. Bad thing is that in global config we still have only "mysql" and "mysqli" so 'mysqlix' setting can be easily lost.

I have also tried with "wrapper" classes (like Joomfish or old Nooku) that works ok on 1.5 but not on 1.6.

Overriding Joomla! 1.6 Framework Classes

You need to be a member of All Together, As A Whole to add comments!

Badge