J3.x, Redirecting issue with com_content links

Hello,

there is a link redirecting issue I cannot solve (J 3.1.5, FC r 1763):

A menu module (swmenu pro) creates content links in a tree view in the form:
option=com_content&view=article&id=<id>.

In J 2.5, these links were converted into the FC context without issues.

In 3.1 however it seems, this conversion happens only sometimes.

In most cases, the items are displayed in core content view instead of FC template view, preventing extra fields from being displayed.

In both cases, the display of the URL does not change in the browser's address line and stays in com_content format. However if I manually change the URL to FC format there, the redirect to FC works normal.

I suspected differences in the category and/or menu configurations, but after hours of investigation I still cannot say why this happens.

What's going on there, and what can I do?


Regards

Hello

question:
a. so the same menu item is sometimes redirected and sometime not redirected
OR
b. some menu items are always redirected and some always not redirected?

and have you noticed something special about those not redirected?

Hi ggppdk,


"question:
a. so the same menu item is sometimes redirected and sometime not redirected
OR
b. some menu items are always redirected and some always not redirected?"

Looks more like case a. Clicking one of the links activates (always) the home menu, but the Itemid is not appended to the URL.


"… and have you noticed something special about those not redirected? "

Yes, I have: in case of the "wrong" links no breadcrumb path is created.

(BTW the usage of the breadcrumb module breaks items display and leads to the following fatal error:

Call to undefined method JPathwaySite::set() in /usr/local/lsws/AMS-NLc/html/_cs/components/com_flexicontent/flexicontent.php on line 179

Deactivating the module does not directly stop message and behaviour, even if I deactivate all caches. Wonder how to stop this).

EDIT: Appending an appropriate Itemid to the URL helps with the pathway error. I only can't find an Itemid that forces the correct link conversion (if that's the reason at all).



Regards

Hello

1. the pathway error occurs when you have enabled parameter "Create pathways automatically"
-- it has been reported and fixed (there will be a new package soon)
-- to fix now just edit file and DELETE the line giving the error

2. about not activating the menu item, that was case in older versions, i will test and if i cannot replicate i will ask you to give me a specific example that shows the problem

Hello ggppdk,

...while debugging queries for the creation of "right" and "wrong" links, I noticed that both ways are mostly in sync until the common template style is loaded.

From that point the "wrong" queries are mostly constructed in a different way, starting with:

This query is missing in the "right" case.

Hopefully a useful hint.


Regards & thanks in advance

try to update
code.google.com/p/flexicontent/downloads/list

... yes, I updated - but still no success

Hello,

finally I found it - hooray!

The reason was a wrong setting of default menu item in the item type, or a conflict of this with the SEF setting in global FC configuration.

I somehow must have gone lost in the multitude of settings

Thanks & regards

Hello

hello, thank you
can provide more feedback?

the menu item that caused the issue was of non-FLEXIcontent type ?

i will test this, since it sound like we need to put some check here (about the default menu item)

Hi ggppdk,

what I did was

- testing different appending methods for the ItemID in fc global config SEF settings, selecting the first entry in the selector
- switching the content items type's default menu item from "site content" in flexicontent hidden menu to a fc category menu entry.

This worked for me, and it looked as if this was the reason, so I gave my feedback.

Crazy thing is: I was wrong - the issue is back - and the above reported might be useless

In summary I see a reproduceable difference in processing com_content links without ItemID appended, coming from different categories with identical settings, starting immediately after the template style loading step.

Luckily, I found a workaround: replacing the URL parts with ReReplacer.

BTW: Glad to see updated FC entry in JED finally - congratulations!


Regards