Assiging

[anil pandit]

Hello 

Is there any way to assign to a template. Am currently using 2 templates in site and when I do and link in the article using the link button ie directly to the content the template it uses is the default and I want to use the second template I have on site.

solution would be appreciated.

--

Mfg
Anil Pandit
www.ieyc.de

[Nils Rückmann]

You can assign template styles to menu items. See Backend->Extensions->Templates.

To use this, you need to have another Itemid for the content the link points to.

[Hannes Papenberg]

No, this is a long standing bug in the Joomla routing that has been actively ignored since shortly before the release of 1.6.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[anil pandit]

This does not work the only work around I can think of is to create a menu item, not publish the menu and then use the link through the menu item instead of content.

I was hoping not to have to create dummy menu items and if there was a way to assign the article(s) directly to a template.

Thanks for the answer.

2012/2/9 Nils Rückmann <in...@nils-rueckmann.de>

You can assign template styles to menu items. See Backend->Extensions->Templates.

To use this, you need to have another Itemid for the content the link points to.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/1DmfRg8JmX8J.

To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[anil pandit]

I agree with u.

[Keith Mountifield]

Hi Anil,

 

Have you tried adding ‘template=**alternate_template_name**’ to the query string on the URL when you create the link? Obviously replace with your template name, if you’re using SEF you should just be able to add that with a ? at the beginning.

 

I’ve just tried this on an old J1.5 site (the only one that I have using multiple templates) and it works perfectly. Dunno if it will still work in more recent versions. I haven’t had the need to try.

 

HTH

 

Keith

[anil pandit]

Hello Keith

This kinda worked for 2.5, but my point was slightly different.

When u write an article and want to embed a link. Use the link button one of option displayed is "content" u find the article u want link all ok so far.

Once the Link is established and when article is displayed and u click on the link the linked article is displayed in the default Template.

The work around work but there is always a problem with the Bread Crumbs.

Thanks - atleast I have learned another way to dissplay an article in a template.

mfg

Anil

[Keith Mountifield]

Hi Anil,

 

Yes, the breadcrumbs will only work for menu items or where you are in an article  /  category view, again I think you can force the category by adding catid=XX or something similar to the URL and that might fix you breadcrumbs.

 

But like you, the only reliable way that I’ve found is to create a ‘placeholder menu’ and create the article menu items in that. The advantage of that method is that you can then assign individual modules to that page, if you have the need.

 

Best

[Stephen Brandon]

While I hesitate to plug my own product on here, I think it will suit Anil's needs completely.

Chameleon (www.metamodpro.com) gives you the ability to asssign templates by any criteria you want, including by article id.

I haven't certified it on J2.5 yet, but will be looking at this on Monday. Someone reported that mostly the J1.7 version works on J2.5, with a couple of bugs. I hope to release the free update next week.

Cheers,

Stephen Brandon

metamodpro.com

[Hannes Papenberg]

The problem is not the inability to assign the template, but the fact that the routing of Joomla is broken and that the article linker plugin does not take care of that fact. The routers in Joomla do not try to find the Itemid and instead defer that task to external classes, like ContentHelperRoute. The article linker plugin only creates links of the type index.php?option=com_content&view=article&id=<article-id>&catid=<catid>. Notice the missing Itemid.

The routing is broken, because JRoute can not know that it needs to apply ContentHelperRoute or maybe WeblinksHelperRoute to this specific URL. We can also not pre-process the URL in the article linker plugin, since that more or less means, that we need to calculate the URLs of all articles. There are two was to solve this issue:
1. Hardcode the Itemid into the article. That means that you need to first find the article and then copy the URL. The downside (beside the bad usability) is, that the URL becomes invalid if you change the menü assignment of that article.

2. Fix the &*!%€ router, like it was described in the at least 2 bug reports and 3 pull requests that I've created so far. (Besides the fact of the improved performance.)

Hannes

--

[Matt Thomas]

Hannes,

Have any of those pull requests ever been responded to?

Best,

Matt

Sent from my phone that uses an open source operating system.

[Hannes Papenberg]

They were closed with differing reasons. One was, that more involvement from the CMS was expected, the other was the fear that it might create a backwards compatibility issue. The backwards compatibility issue would be, that URL extensions are made obsolete.

[Matt Thomas]

I'd personally love to see Joomla's router improved. Is this something that can be posted on the tracker so we can test it?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[anil pandit]

Hello Matt

I looked at your product, looks good, this make it easy to assign a template but as Hannes pointed out it is chained process that creates issue.

We should try and get this issue resolved as I feel linking is a core function on any site. Unfortunately I dont know how to get this addressed through the Joomla Web (forgive the pun). However willing to do so if someone guides me.

mfg

Anil

Mfg
Anil Pandit
www.ieyc.de

[Matt Thomas]

Hi Anil,

Thanks! Construct basically works within Joomla's current router, but I believe Hannes' solution can resolve the root cause. I have seen some of his router work in the past and it's great. Would love to see it in the core. Maybe his pull requests can be revived for 3.0?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[elin]

Overall we should not  do a single thing that even potentially impacts people's urls which in turn potentially impacts their site traffic and livelihoods. For 3.0 people can and certainly should look at it (and now is the time to start working since it is probably a 4-5 month project to do in a serious way) but the goal should be no breakage of anyone's existing urls when they migrate. There are quite a lot of complex issues including handling the language segments and how that might work with UCM. Actually in general we should be having a discussion about ucm routes since that's where there is real freedom.

There were a number of good threads and forum discussions on routing issues prior to the release of 1.6, in particular I remember one in the white papers forum that people interested in this will want to review. 

Elin

[Hannes Papenberg]

I think that paper was written by me.

Regarding the router work: it is done and it is 100% backwards compatible. It even reduces duplicate URLs. It is faster, more flexible and A LOT easier to code. It is also 100% UCM compatible.

Hannes

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/7JZ_y-mwbjwJ.

[Niels Braczek]

Am 13.02.2012 18:08, schrieb Hannes Papenberg:

> Regarding the router work: it is done and it is 100% backwards compatible.
> It even reduces duplicate URLs. It is faster, more flexible and A LOT
> easier to code. It is also 100% UCM compatible.

Can we *please* get this into the core?

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[elin]

Write the automated tests for all possible scenarios.

Elin

[Niels Braczek]

Am 13.02.2012 18:26, schrieb elin:

> Write the automated tests for all possible scenarios.

I try not to be offended. Where are the automated tests for all possible
scenarios regarding captcha and update of phpMailer from 5.1 to 5.2,
which both broke a site of mine on an update from 1.73 to 2.5.1?

Hannes has done a great efford to improve the router. It passes all
*existent* tests. That's all we can ever ask for.

[Al Warren]

Define all possible scenarios.

[elin]

Well this is the fundamental problem of routing in 1.5/1.6+, you think you have it solved but then your find that you don't really because there is some combination that has not been accounted for. And that's where you end up messing up someone's search engine results and incoming external links and generating 404s. So all possible scenarios would include but not be limited to  (this is how I manually test proposed changes to the router when I'm deeply into it):

Set 1, top priority

1. Items with no direct or indirect menu connections (i.e. In a category that never has menu links anywhere up the branch all the way to root)

2. Layouts with direct menu connections at different menu levels.

3. Layouts with indirect menu connections such as if the category or ancestor category has a link but the specific layout (whether category or item) in question does not have one.

4. Layouts with the multilingual plugin turned on. 

Set 2 items in text

3. All drill down links that are programmatically produced from items linked from menus and from items not linked from menus.

4. Layouts using the index.php?itemid=xx format inside of content but not programmatically produced.

5. Layouts using generated non sef links without itemIds such as those produced by the  article plugin (but for all content types)

More complex scenarios

6. Layouts where the linking takes place at different depths on the menu structure, i.e. where the base sef URL from which the link is being generated includes 0, 1,2,3,more segments.

7. For categories, links that move users to parent, child and sibling views and then from those views move again to parent child and sibling view.

So for each type of "page" you would need to test all of the above scenarios.

Then you need to carefully define the expected behavior especially in situations where the webmaster has made two or more direct or indirect links to a particular item. Webmasters often create distinct pages with the same content items but different layouts and surrounding modules making them different (non duplicate) content but with the same exact ids and php urls produced. This is valid behavior and must be respected. For example you might have two blog layouts to the same category, one showing 1 item and the category description and another showing 20 items and no category description and each having a totally different array of modules. These will have the same URLs but different ItemIds, so when the router hits that url without an itemId which one does it pick? That's where the standard rules built into the router come into play.

You need to test this with and without Apache rewrite enabled.

Currently the expected behavior is that for direct menu links the url will match exactly the menu structure. 

For indirect links the url should start with the segments defined by the holding menu structure and then append only the segments starting from the category linked from the menu.

 No segments should ever be repeated. 

I would love to see some just produce a body of test data that includes a ton of potential urls with the expected results. I think that would help tremendously if people could agree on what is expected.

This is just the beginning of the work that has to be done and that the jbs and others have spent years on testing. Still, today, we continue to find undocumented scenarios (JM found one this weekend where routing was producing a 404 for example, yet this was never reported before even a year into the release).  In the end hopefully in the 3.x series we get a routing solution that allows webmasters to craft the exact urls that they want completely independent of the menu and category structure (unless they opt into using those structure) if they are using UCM. 

I'm not a computer scientist but my understanding is that the fundamental problem with routing as it exists now in Joomla is that it relates to issues of complexity theory and NP completeness  http://en.wikipedia.org/wiki/P_versus_NP_problem .. it is a problem that is not going to be easily solvable however optimistic we might be about one approach or another. In fact it may not be solvable at all in an absolute sense, but what we do is do the best approximation to a consistent, usable solution that we can manage by listing out and testing as complete a set of scenarios as we can. 

Elin

[Hannes Papenberg]

Might take me a few days, but expect those tests soon.

Hannes

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/F8aDPg1ueJ0J.

[Niels Braczek]

Am 15.02.2012 07:36, schrieb Hannes Papenberg:

> Might take me a few days, but expect those tests soon.

Great news, thank you, Hannes!

[Tobi]

+ 1 for the new routing!

[Matt Thomas]

That's awesome Hannes, thank you!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

[Al Warren]

I think the whole problem is that the original idea of displaying a template based on a menu item was just a quick bandaid solution. The problem is not that routing is broken. The problem is that it was a flawed solution to begin with. The approach shouldn't be that a template is assigned to a menu item. The approach should be that an element requests a template.

If you want to choose a template, there needs to be a rational decision process. One way to do that is for each displayable element to be able to request a template. That is, a module, component, menu item, etc. can request a certain template. That request is stored in a separate table with some form of precedence data. So, for each template in the table, you might have multiple entries. And then, for templates that exist in the table (no entries if it's not requests for a template), you choose based on some precedence scheme. It could be a simple as an ordering column or as complex as assigning precedence to certain types of elements. Look, just before the html is rendered, we know what's going to be displayed. We have all the information we need to choose a template. Why not take advantage of that.

If you wan't to break free of any implied problems with routing and template assignment, the simplest approach would be to take routing completely out of the equation. Only then will you be totally liberated from Itemid. After all, that's where it all began. The dreaded Itemid. Who needs it? Really. Think about it.

[Al Warren]

I really wish you could preview or edit these posts. I always miss something.

I'm sure the approach to template choice has been hashed many times. I wouldn't know. I've been away for a few years.But I really do think the logic/code could be completely refactored without breaking backwards compatibility. I'm not going to touch it. But suffice it to say it should have been re-examined a long time ago. I'm just surprised no one thought of separating template choice from routing. It seems such a logical conclusion. But that's just me.

[Stephen Brandon]

On 16/02/2012, at 3:15 AM, Al Warren wrote:

I think the whole problem is that the original idea of displaying a template based on a menu item was just a quick bandaid solution.

Perhaps is was, but it also plugs into the original philosophy (perhaps from Mambo days) that the menu item is the foundational unit of the web site. Back when a com_content item was almost all you could assign to a menu item, that was fair enough. As components have gotten ever more complex, the assignment of modules and templates by menu item gets more and more, can I say it, absurd.

I'm not sure about your assertion that an element requests a template. I think that the site designer requests a template for different parts of the site. If an element requests a template, then this makes the template element-specific - but what about factors that are not tied to elements, like per-user, per-group, per-session, time-based, cookie-based, per-subdomain, etc?

I have even developed a component to be able to do this.

The philosophy is this:

- design a set of rules to decide which template style should be used. This is analogous to your idea of precedence rules.

- each rule can detect things like menu item (if you want it to), individual article, user, group, category, browser, component, URL, referrer, JRequest parameters or component-specific data via plugins, etc etc.

- as a result of any rule a template style can be chosen, or other actions performed. Optionally, the rule chain can then be stopped, or the next rule evaluated.

- variables can be introduced (via session variables or permanent cookies) to allow rule outcomes to be remembered within/between sessions

What I love about this system is that not only does it free the templates from the Itemid associations, but it gives me control, as a site designer, over what parts of the site, and under what conditions, templates should be used. It does this all in one place so I can see at a glance what the decision-making flow-chart does.

i.e. as a site designer/admin my thinking about templates goes "I want the default template to be X, but for logged-in users I want Y, except for VirtueMart Checkout when I want Z for all users. If people come in via subdomain foo.site.com then they should have template N instead of X or Y."

A rule-based system such as mine allows you to actually represent that train of thought in a succession of rules. Any system (such as the current Itemid-based system) that requires individual elements to request a particular template requires me to translate my thought process into "VirtueMart now needs to be able to request different template for different page types, so I assign one template in there; I need to go into the User system to assign some sort of template to logged-in users; some other part of the config needs to be changed to allow subdomains to use a different template". Of course, few of these things are even currently possible in Joomla, and even if they were there would be issues of precedence. And you're jumping all over the system to set the template in disparate locations.

So my system does not require individual components/modules etc to have to support some sort of "request" for a template. That's taken out of the component's hands.

Now, could that system be introduced into core Joomla? Perhaps, but compared to the current (2.5) system of being able to select a template style per menu item, when editing the menu item, such a system would surely be seen as something for power users.

So what might a system look like that was designed such that an entry-level site admin could come to grips with it easily, and still gives flexibility to extend to more complex use cases?

Cheers,

Stephen

www.metamodpro.com

The problem is not that routing is broken. The problem is that it was a flawed solution to begin with. The approach shouldn't be that a template is assigned to a menu item. The approach should be that an element requests a template.

If you want to choose a template, there needs to be a rational decision process. One way to do that is for each displayable element to be able to request a template. That is, a module, component, menu item, etc. can request a certain template. That request is stored in a separate table with some form of precedence data. So, for each template in the table, you might have multiple entries. And then, for templates that exist in the table (no entries if it's not requests for a template), you choose based on some precedence scheme. It could be a simple as an ordering column or as complex as assigning precedence to certain types of elements. Look, just before the html is rendered, we know what's going to be displayed. We have all the information we need to choose a template. Why not take advantage of that.

If you wan't to break free of any implied problems with routing and template assignment, the simplest approach would be to take routing completely out of the equation. Only then will you be totally liberated from Itemid. After all, that's where it all began. The dreaded Itemid. Who needs it? Really. Think about it.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/iuImM-xF3boJ.

[Hannes Papenberg]

Ok, I tried to write those tests today and as it seems, the unittests of
the CMS are completely non-funtional.

Tell me how to write the tests and I will have a go.

However, the current situation raises the question why apparently
features have been added to the CMS without tests and now they are
required for this feature. Looks like the last time anything substantial
was done to the unittests in the CMS repo was about a year ago (March
2011) So neither 1.7 nor 2.5 were covered by them.

Hannes

Am 15.02.2012 07:36, schrieb Hannes Papenberg:
>

> Might take me a few days, but expect those tests soon.
>
> Hannes
>
> Am 15.02.2012 00:50 schrieb "elin" <elin....@gmail.com

> <mailto:elin....@gmail.com>>:

> <mailto:joomla-de...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com

> <mailto:joomla-dev-general%2Bunsu...@googlegroups.com>.

[Rouven Weßling]

On 22.02.2012, at 15:06, Hannes Papenberg wrote:

Ok, I tried to write those tests today and as it seems, the unittests of
the CMS are completely non-funtional.

Indeed the current unit tests are broken beyond repair. The current plan is to remote them completely while making sure we don't loose any for classes in the platform. We'll than add new unit tests based on the groundwork done by the framework, this will require phpunit 3.6. However we can't really do that until Mark has had the time to adapt because he still regularly runs some of them (and AFAIK he's the only one doing so)

However, the current situation raises the question why apparently
features have been added to the CMS without tests and now they are
required for this feature. Looks like the last time anything substantial
was done to the unittests in the CMS repo was about a year ago (March
2011) So neither 1.7 nor 2.5 were covered by them.

Well we still have the platform unit tests and the system tests - which are regularly run by Mark - so it's not that bad but yes the situation is far from perfect. I'm not sure what kinda testing you want to do, but some of it would probably go into the platform, wouldn't it?

Rouven

[Hannes Papenberg]

Actually, these would be cms-only tests. Testing would mean to create a dummy component with a dummy router that tests all possible URLs that can come out of the rules in the router plugin. So you see that the main part of this is not part of the platform.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[Mark Dexter]

We don't have any unit tests for any non-platform classes. I don't think anyone has tried to figure out how you would write them for this type of CMS class.

In this case, it might make more sense to create a thorough set of manual tests to check that we have good b/c with the existing router and document that in the test instructions in the tracker. Mark