What does Joomla 1.6 bring to the average Joomla user? In practical terms: not much
In reality it introduces a troublesome ACL, enhancements to the core of 1.5 with the addition of the jXtended libraries (already available for 1.5), there are framework changes that do make the extension of forms easier in the backend (but this is something do-able even now with some PHP, no biggie) and some tidbits here and there. Oh, not to forget! The admin theme is now blue-ish.
Meanwhile WordPress and Drupal show significant signs of improvement and at least indicate that the people behind them take the future of their CMS very seriously. Although I don't generally agree with their marketing model, they're doing one hell of a job "distracting" people to them, when Joomla is far superior "by design" from these CMSs ladies and gentlemen. Just try developing your first plugin, module or whatever in Drupal or WordPress! Ha!
Back to the Joomla world, what's the status of 1.6? Well, let's just say it's possibly not coming in 2010. There are many things that simply cannot move forward for many reasons:
- too much bureaucracy?
- lack of professional involvement to stir goals and development
- lack of money to support development
There may be more and -don't get me wrong- they are valid reasons, cause, hey, it's not a perfect world.
"So what's your point?" you may ask...
My point is this: forget about Joomla 1.6. Move on to Joomla 2.0.
How do we do that? We take 1.5 and we supercharge it:
- separate components into standalone applications and minimize dependance between components and the core of Joomla
- remove all the garbage (weblinks, newsfeeds, polls etc.)
- introduce the concept of "installation profiles", e.g. install Joomla from scratch to use as a blog or portal or whatever you want. Make it easy for professional integrators and template designers to pack websites easily. It's no biggie. This can lead to different "sample data" packages and content setups.
- improve the current framework in very specific points. Fix any bugs (e.g. modules not being able to attach stuff to the <head> of the document when the cache is on"
- improve performance. The work is there. Klas has pointed out the weaknesses of the current caching layer. Add his fixes in and move on. Next stop will be to better handle application load (and server load) when we have cases where users need to be logged in and therefore the cache cannot work. Maybe a mechanism to select which elements to cache or a mechanism similar to what Ning uses: Cache everything and attach some query strings to certain user-interaction related links so that the application fetches fresh content. This is a simple, tried and tested way.
- Create a unified installer for everything. Use the concept of the manifest.xml file to install 1,2,3 or 12 extensions at a time. That way you can install a plugin and 2 accompanying modules without telling the user to install them separately or write a component to act as the intermediate.
- Forget com_content. Want more? Use K2 for core content. It's completely separated from the core yet 100% tied to the framework. It doesn't suck with menu item ids. It's veeery familiar to com_content. This will boost 1.5's features to 2.0-ish and slap Drupal and WordPress in the face. Think comments and tags and basic content ACL is difficult? Come on? It's all about decision making.
- Internationalization: include the excellent "unicode slugs" plugin from Jean-Marie Simonet to create unicode capable URLs. It's here already and it's free under GPL.
- Extend the default "content elements" for all extensions so that less experienced devs can create a simple plugin that has a "content category" selector which doesn't suck.
- Improve the media manager a bit with the addition of more actions. Upload and delete is not enough.
- Add a new admin template that just doesn't suck. There are many people out there that have fresh ideas and can significantly help. Sticking to the same Mambo-like pattern just doesn't cut it anymore.
- Make all Joomla 1.5 extensions and templates MVC capable so that template devs can rip the thing out and create amazing templates both for the frontend and the backend.
There are more to be added of course and I got a whole list for that, but these are the most important perhaps.
The key word here of course is "initiative". I believe that software development is like real life relationships. If you drag the thing over and over it will eventually lead to a break up. You have to be able to transform when circumstances demand.
What are your thoughts?
P.S. For those trying to read "between the lines", no, I'm not talking about a fork of Joomla I'm talking about advancing Joomla and how I'd like to see things for v2.0. Jeez...
This is a guide to save you from banging your head against a wall, in case you ever want to get PHP talk with Ingres on a CentOS machine.
After hours of searching around and not finding not one damn proper guide, I decided to just write one down (after much trial and error).
What we wanna do is basically query an Ingres database through a CentOS based LAMP server (which runs WHM/CPanel too). So we need to install (unfortunately) the Ingres Community Database (as the PECL Ingres package seems to require it to be installed) and of course we need to install PHP's package for Ingres (PECL Ingres) so we can query an Ingres database from PHP. Still with me?
Let's get started...
1. Install Ingres and PHP/Ingres support on CentOS:
Install Ingres DB Community Edition first as it's obviously required by PECL's Ingres package. Here we install the related RPM for a 32-bit CentOS machine. The process is the same for 64-bit, the file is just different. Sign up on ingres.com for a free account and go to http://www.ingres.com/downloads/ingres-database.php to download the right release. Ingres.com is passing the download link from some script, so if you wanna pinpoint the URL and not download the file to your PC, then upload onto your server, you can simply right-click on the download manager in Firefox and copy the "link location". This will give you the URL where the actual file of the Ingres db relies on the ingres.com site, so you can use "wget". In this case, the path I got was something like "http://184.108.40.206/~GqxCOi/ingres-10.0.0-119-NPTL-gpl-pc-linux-i386.tgz". Don't try this link in particular as it may not work when you read this...
You obviously need root access to the server:
# cd /usr/src # wget http://220.127.116.11/~GqxCOi/ingres-10.0.0-119-NPTL-gpl-pc-linux-i386.tgz # tar -zxvf ingres-10.0.0-119-NPTL-gpl-pc-linux-i386.tgz # cd ingres-10.0.0-119-NPTL-gpl-pc-linux-i386 # sh ingres_express_install.sh
This process will install Ingres in /opt/Ingres/IngresII/2. Install the PECL Ingres package for PHP.
Using "pecl install ingres" will simply NOT work. So we do it the old-fashioned way. Grab the latest package here: http://pecl.php.net/package/ingres and then do the following:
# cd /usr/src # wget http://pecl.php.net/get/ingres-2.2.2.tgz # tar -zxvf ingres-2.2.2.tgz # cd ingres-2.2.2 # phpize # ./configure --with-ingres=/opt/Ingres/IngresII # make # make install
This process will install the PECL Ingres package for PHP.We need a couple more things, before we get started.
We need to declare some system variables in Apache. If you use WHM/CPanel, go to Main >> Service Configuration >> Apache Configuration >> Include Editor and choose to edit the "Pre Main Include" file. Add the following 2 lines:
SetEnv II_SYSTEM /opt/Ingres/IngresII SetEnv LD_LIBRARY_PATH /opt/Ingres/IngresII/ingres/lib
If you don't use Cpanel, just paste these lines into your httpd.conf file.Now locate the WHM/CPanel php.ini file at /usr/local/lib/php.ini (if you don't use WHM/Cpanel it's probably located in /usr/lib/php.ini). Find the line "; Directory in which the loadable extensions (modules) reside." and right after that add:
extension = "ingres.so"
This will make sure the related PHP extension for Ingres support is loaded by PHP.That's it.Go to your "public_html" folder (or any other folder) and test if you got Ingres support for PHP installed properly. We'll use a dummy connection file, so get the code below:
<?php $link = ingres_connect("database", "user", "password") or die("Could not connect: " . ingres_error($link)); echo "Connected successfully"; ?>
…and save this as "ingres.php". Now visit this file from your browser and if you get a "Warning: ingres_connect()..." then it means Ingress support for PHP is installed properly!Enjoy!
Here's an easy trick to replace the built-in Mootools library that comes in Joomla 1.5 with a compressed copy from Google AJAX Libraries API:
There are 2 speed benefits by following this approach:
- We load a compressed copy of Mootools, so from around 73kb it drops to 18kb!
- We load Mootools from Google, thus our browser can simultaneously (in parallel) download Mootools along with the rest of our site's content.
It's a simple & easy trick we use on all our web projects, big or small. ;)
- Establish naming conventions. Do not assume you'll always be the one coding for a particular site. Never use generic names for classes, IDs and form names in your code like “comment” or “article”. Someone else may do so too, so you can kiss your app’s functionality bye-bye!
- Avoid inline CSS like the plague.
- Try to squeeze as much CSS code as possible into one file. Less CSS files means faster loading of your site's design on the browser.
- Avoid placing UI images inside your HTML code. UI images belong to given UI templates (home, category lists, product catalog, article etc.) and therefore are loaded on every page request. Placing such images as "background images" in your CSS file allows the browser to cache them the first time it renders them, which means your site will load faster on subsequent requests for your visitors.
- If you code on PHP, check out the Tidy library. Enable it when you can as it will easily point out (and fix) bad markup in your HTML.
- For God’s sake use an open source CMS, don’t re-invent the wheel, make it possible to contribute back. Joomla, Drupal, Wordpress are enterprise class CMSs to get started with and some of the most popular websites in the world are powered by these open source CMSs.
I was recently looking for a clean solution to prevent the display of module positions on gazzetta.gr - the 2nd most high traffic Joomla website, after joomla.org.
The first thing that came to mind was the htaccess trick I had spotted on the Joomla forums here: http://forum.joomla.org/viewtopic.php?p=1887090#p1887090
Thing is, this rule does not work if you have SEF on and you’re in some inside page.
So I just wrote a simple solution which is PHP based and you can include right at the top of your Joomla template for ease of maintenance (template designers can use this too as an XML option ;) )…
Make sure the following code goes at the very top of your template's index.php file, but within <?php and ?> tags:
// Properly prevent ?tp=1 module position exposure on Joomla sites using PHP only$currentURL = explode('?',substr(JURI::base(),0,-1).$_SERVER['REQUEST_URI']);if($_GET['tp']) header('Location: '.$currentURL);
UPDATE: There seems to be a Joomla API solution for that. Thanks to Cory Webb for letting me know. Both solution follow...