This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » eZ Publish 5 Platform » after setting tree_root all request...
expandshrink

after setting tree_root all request for the new siteaccess go through the legacy kernel

after setting tree_root all request for the new siteaccess go through the legacy kernel

Monday 22 September 2014 8:14:35 pm - 8 replies

I have added a new siteaccess that is a copy of the default eng access with a tree_root set.

Any page on this new siteacccess is returned through the LegacyKernelController::indexAction according to the symfony debug toolbar.

Is this expected?  This seems odd to me and creates a dependency on the legacy having to be configured too for the siteaccess even if it does not depend on it.

Monday 22 September 2014 9:00:08 pm

I would say is expected depending on how you have defined your overrides.

You need to be sure that your overrides also applies to your new siteaccess. 

We can see a similar case with eZDemoBundle. As you can see here and here.

As you see, ezdemo_frontend_group is kinda a "group of siteaccess". eng and fre are in this group. 

location_view is defined for that group. So, if you add a new siteaccess, let's called "esl", you need to add "esl" to that ezdemo_frontend_group, If not, those overrides won't take any effect on your new siteaccess and there is where legacy templates are loaded.

Monday 22 September 2014 9:44:38 pm

I had suspected that too but I had added the new site access to ezdemo_frontend_group and I get the same response.

Just to confirm I changed the tree_root location_id of the default eng site access and it too end ups using the LegacyKernelController::indexAction also.

Any other ideas?

Tuesday 23 September 2014 10:20:25 am

Hi Douglas

Can you please show your config in an embedded gist ?

Tuesday 23 September 2014 3:15:02 pm

Sure below is the gist.

I  have hunted the issue down further and I find that in eZ\Bundle\EzPublishCoreBundle\Routing\UrlAliasRouter::getUrlAlias there is a call to $this->generator->getPathPrefixByRootLocationId( $this->rootLocationId ) that is adding a prefix when none should be.

In the log I see
Router eZ\Bundle\EzPublishCoreBundle\Routing\UrlAliasRouter was not able to match, message "Could not find 'URLAlias' with identifier 'site1/site1'"

How do I get rid of this prefix? 

EDIT:

I tried using the insert gist but it was not appearing here is the link https://gist.github.com/wizhippo/e1919cf1b06350c8e2bb

Modified on Tuesday 23 September 2014 3:19:30 pm by Douglas Hammond

Tuesday 23 September 2014 4:43:10 pm

@Douglas: You can embed the gist by clicking the <?> button and choosing "Gist snippet".

Tuesday 23 September 2014 4:52:55 pm

I did that but it did not show even after adding the gist link and the filename.

just for fun here it is:

The gist should be above this line

 

To further my research I did a fresh install of ezp5, then changed the root_not for the default eng site.

Same issue so it's not something specific to my setup.  I believe this to be a bug now.

Modified on Wednesday 24 September 2014 3:39:54 pm by Douglas Hammond

Tuesday 23 September 2014 8:22:58 pm

I found the issue. The fix that was just committed for EZP-23337 breaks the multi-site support and causes a redirect when it should happen.

Modified on Tuesday 23 September 2014 8:33:12 pm by Douglas Hammond

Wednesday 24 September 2014 7:00:49 am

Hello,

Here is a link to the issue ticket mentioned above by Douglas: https://jira.ez.no/browse/EZP-23337

@Douglas

I figured out why your gist is not displaying correctly (by reverse engineering)

Your url to the gist contains the file name when it should not. The url to the gist field should only contain this string, 'https://gist.github.com/wizhippo/e1919cf1b06350c8e2bb'. Also you left the gist file name field (field just below the url to gist field) empty when it should only contain this string, 'ezpublish.yml'.

I'll prove this to you by embedding your gist in my post.

See. It's that simple. You can edit your post(s) again and fix your gist using web browser inspection edits to the post html (complicated but possible) or delete the gist custom tag and embed it again from scratch.

I hope this helps!

Cheers,
Heath 

Modified on Wednesday 24 September 2014 7:06:15 am by // Heath

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from