Joomla! 1.6 Subtle Changes Important to Understand
I thought it might be helpful to start a discussion on changes developers and site builders find as we work with Joomla! 1.6. Sometimes, small changes in logic can create real opportunity we might miss and differences that might be a little challenging to overcome.
Please share any changes you see in the code or behavior of the application that might help others. Also, as with all things on ATAAW, this is not a support forum but rather a discussion by professionals on the code base. User questions should continue to go to the Forums.
Tags: Joomla! 1.6
Views: 1135
Replies to This Discussion
-
Permalink Reply by Manoel J. Silva on -
In J! 1.5 -> quick view of module positions = ?tp=1 at the end of the url
In J! 1.6 -> Go to Extensions -> Template Manager -> Options -> Preview Module Positions = Enable
Save and Close!
-
Permalink Reply by Amy Stephen on
-
In Joomla! 1.6, the router BuildRoute logic for each Component was changed to require a Menu Item in order to build the link.
// we need a menu item. Either the one specified in the query, or the current active one if none specified
if (empty($query['Itemid'])) {
$menuItem = $menu->getActive();
}
else {
$menuItem = $menu->getItem($query['Itemid']);
}
There continue to be problems with the router. It is not uncommon to see a URL that bears the existing page URL as the "base" (if you will), followed by it's real URL. Look for these situations and report them on the tracker.
For those who have been around long enough, forcing the Menu Item on the URL was done in 1.0.12 and it turned out poorly.
All these years later, Joomla!'s ItemID continues to present architectural challenges. I have long believed Joomla! must adopt an approach where URLs are strictly associated with content items and ensure there is only one URL per item. Some Menu Item pages _are_ indeed unique content (ex. category blog page), and thus should have a URL created for that item, but Content URLs must be derived from a pattern that is tied to the content itself (ex. date, date parts, category alias, article alias, article id, and so on.) not to the page it is presented on (which could be many) _and_ the content, too.
No matter how many times you try, you cannot do the impossible. Trying to support a system of unduplicated content means you need to pick how that URL is generated - you can't allow the menu and item both to do their thing. It just does not work.
-
Permalink Reply by Brian Towles on -
Amy Stephen said:
All these years later, Joomla!'s ItemID continues to present architectural challenges. I have long believed Joomla! must adopt an approach where URLs are strictly associated with content items and ensure there is only one URL per item. Some Menu Item pages _are_ indeed unique content (ex. category blog page), and thus should have a URL created for that item, but Content URLs must be derived from a pattern that is tied to the content itself (ex. date, date parts, category alias, article alias, article id, and so on.) not to the page it is presented on (which could be many) _and_ the content, too.
I disagree with this to a point.
The concept that Joomla should be trying to support a system of unduplicated content I think is based on a want for programatic simplicity not based on the end users needs. The segmentation of page (URL) from content I think is a key benefit of any CMS. Without it you wouldn't have the front page listing out portions of the content with links to full articles.
More then that, saying a user can only present content from only one path through a site is just limiting flexibility and assuming as developers we know whats best for an end user and not looking to the user for their needs. A user may want the presentation and branding of a particular piece of content to look completely different based on the users path through their site in order to better target their audience. An example might be a health site presenting an article changing the layout, look, ads, and background color based on if the user comes from a Men's Health vs a Woman's Health side of the site.
Amy Stephen said:
No matter how many times you try, you cannot do the impossible. Trying to support a system of unduplicated content means you need to pick how that URL is generated - you can't allow the menu and item both to do their thing. It just does not work.
Now I agree that you can't allow the menu and item both to do their thing but from that standpoint of enforcing the "page" metaphor. Really, I do not feel a content item should have an independent URL or access method at all with out going through some sort of structured presentation layer. The menu system is that system for now but is still somewhat limiting.
-
-
Brian -
I think we might be saying the same thing. If you read Berner-Lees Cool URIs don't change, he clearly distinguishes between unique content (like an article, or an image, for example), and those summary pages that list "Latest News" or "My Profile page."
Joomla! actually does a great job of allowing Site Builders to reuse content and present it in interesting ways for different audiences. This is done through the use of Modules (ex. Latest News) and through Menu Items like Front page or Blog Category, and son on.
Like I said above:
Some Menu Item pages _are_ indeed unique content (ex. category blog page), and thus should have a URL created for that item, but Content URLs must be derived from a pattern that is tied to the content itself
But when it gets down to a content item (whether you click the Read More link on a Category Blog, or the Title Link in a Latest News Module), it should have one, and only one URL that is used each and every time the item is referred in the application, and that value should not change. (Or, if it does, it should be known and 301 redirected if presented as a Request.)
The challenge to accomplish that is a developer one. The need to accomplish that is a User issue. Having ambiguity of URI for your content means it is far more difficult to share with others, to build good Page Rank, to be "data" that can be combined in useful ways as a Mashup, and so on.
When Berners-Lee created the WWW, he intended it to serve as a database, of sorts. He had already conceptualized the Semantic Web. The rest of us in our rush to publish online did not give this near as much consideration, and as a result, we have a mess on our hands. If we want Joomla! to participate in Semantic technologies then our Web sites must have detail content categorized in such a way that it can be retrieved the same way, every time.
Again, I think we are agreeing. Content can and should be combined in useful ways on "summary" pages like the Frontpage and Blog Category Menu Items. Joomla!'s Modules that display a bit of content on a page are very useful. But when that single item is linked and clicked, it should be easy to determine, consistent, and singular.
-
-
On the day of release, the way Language files are loaded for Joomla! 1.6 Plugins was changed. As a result, all Plugins must add the following code:
public function __construct(& $subject, $config) {
parent::__construct($subject, $config);
$this->loadLanguage();
}
-
Permalink Reply by Brian Towles on
-
Along the lines of Language stuff, Joolma moved from its own ini parser for language files to just using the php parse_ini_file and parse_ini_string. These are much stricter when dealing with non alphanumerics in the value and usually needs to be quoted.
As well no more hash (#) for comments. Semicolon (;) is the preferred now for comments.
-
-
System Image files, like email and print icons, are now in media/system folder. To override in your template, you must place those files into the template/images/system folder.
See discussion and topic Template print and email icons override not faking affect in Joomla...
-
Permalink Reply by Youjoomla on -
Not sure if this was mentioned before or if it is in the docs. but
Fast way to get template params and use them in your apps is
<?php
$app = JFactory::getApplication('site');
$name_your_params = $app->getTemplate(true)->params;
$param1 = $name_your_params->get('param1');
echo $param1
?>
usage example would be aditional parameter for your featured articles
the code above can be placed in
templates/html/com_content/featured/default_item.php
-
Permalink Reply by Youjoomla on
-
Accsessing component parameters in frontend for specific menu item, we will use com_content as example :
in 1.5 this was done with
<?php
$mycom_params = JComponentHelper::getParams('com_content');
echo $mycom_params->get('num_leading_articles');
?>
above code in joomla 1.6will output the DEFAULT com_content params , not affected with menu item
so the new code for 1.6 would be
<?php
$app = JFactory::getApplication('site');
mycom_params = & $app->getParams('com_content');
echo $mycom_params->get('num_leading_articles');
?>
-
-
Plugin Parameters
In 1.5, you had to use the Plugin Helper to retrieve the Plugin object and then JParameter to retrieve the Parameter Object. Following those steps, you could work with a single parameter.
<?php
$plugin = & JPluginHelper::getPlugin('content', 'emailcloak');
$pluginParams = new JParameter($plugin->params);
$mode = $pluginParams->def('mode', 1);
?>
In 1.6,Joomla makes the parameter object automatically available to you.
<?php
$mode = $this->params->def('mode', 1);
?>
-
Permalink Reply by Arelowo Alao on -
Hello I'm a joomla extension developer and I'm trying to make my extension compatible with 1.6. One thing I did notice is that when I install my component the sub menus don't show up also my extention name is changed to remove spaces. here is a sample of my xml install file.
<submenu>
P.S I was also looking at the jos_extentions tables and I don't see a reference to my component. Can someone explain the change since the jos_componet table is not gone...
<menu img="../components/com_maianmedia/media/thumb/about.png" link="option=com_maianmedia&task=about">About</menu>
</submenu>
Now this created the sub-menu in the component drop-down however when your navigating through the component I don't see the sub menus above the view...
-
Permalink Reply by Marco Biagioni on -
I'm wondering about J1.6 ACL implementation. This is a real complication for users, developers etc. I find that maybe it could be implemented giving an easier way to use it as a user and as a developer. Moreover i imagine that for most scared users it will appear redundant...i think it isn't important give permission to a single entity like an article. On the other side it fire a lot of complications that make it quite useless. I noticed that J1.0 and J1.5 had an untermined job...his name is PHPGacl...i would have better understood to complete this implementation in a really useful way, and there was all the requisites inside this library to obtain good results. Finally, i think it should be avoided a double inheritance mechanism (identities merging), levels + groups because it is very hard to manage also using all the widgets you want. Someone of my own idea?
© 2012 Created by Amy Stephen.
