Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: ee()->uri reporting URI containing language variable

Status	Resolved
Add-on / Version	Publisher 2.9.0
Severity
EE Version	4.3.4

0to9 Cross Creative Agency

Sep 19, 2018

Description:

I’ve recently updated a site from EE3 to EE4 (and updated from EE2 to EE3 a few months ago). In the process, I’ve updated Publisher from 2.7.3 to 2.9.0. It seems ee()->uri now returns the page URI with the language short code intact; is this intended behavior? It seems to break Structure’s {structure:page:*} global variables.

Is my install missing a hook modifying the URI passed along from ee()->uri somewhere, perhaps? The ‘old’ install (EE3 on 2.7.3) returns the URI without language var.

Can you tell me where the lang var is stripped out of the URI?

Managed to ‘hotfix’ the issue by stripping the var out in Structure, but thats not something I’d want to leave there.

0to9 Cross Creative Agency

Okay this is odd;

When I output ee()->uri->uri_string() in the ext.structure.php file, it returns a variable with language segment.

However, when I run <?=ee()->uri->uri_string();?> from a PHP enabled template, there is no language segment.

Is this a ‘parsing order’ issue, in that structure is accessing the current URI before Publisher manages to get it’s hands on it?

0to9 Cross Creative Agency

(Also note that on the old situation, which I still have running on the live site, both instances have the language segment stripped from the uri)

BoldMinded (Brian)

Its possible its a hook order issue, but this is odd b/c I haven’t had any similar reports of something not working correctly with the uri between Publisher and Structure. That part has been pretty solid for some time.

BoldMinded (Brian)

The only places Publisher is setting uri_string are the following (ignore the 2nd one, its a test file). All of these lines of code, and most of the code around it have been unchanged for quite awhile. For example the 4th line of code is in a function that has not changed since 2016, and the other ones are 2014 and 2016. I’m skeptical that this is suddenly an issue, otherwise I’d be seeing similar reports from other people. uri->uri_string is not supposed to have the language code in it (note the array_shift method calls).

https://d.pr/i/XPIBS5

0to9 Cross Creative Agency

It seems the Ext.structure.php extension is called before the Ext.publisher.php extension. Not sure how I can change that.

(Tested by adding an echo in session_start in Structure ext, and an echo in setUriString() in Frontend service in Publisher. On this site, the Structure echo shows first. In other sites with this very same combination, the Publisher echo always shows first.

Is there a way I can influence in which order these are run?

BoldMinded (Brian)

Yes, there is a priority column in the exp_extensions table. Lower # is first, higher is last. If you know which hook it is (probably core_boot or sessions_start/end) then you can change it there. Let me know which hook you change, what the original priority was, and what you changed it to to see if I can replicate it locally.

0to9 Cross Creative Agency

Publisher_ext - Core_boot is set to 1 Structure_ext - sessions_start (and _end) set to 10.

These should not run in the order they run :(

BoldMinded (Brian)

core_boot actually happens after sessions_start and sessions_end, so regardless of order, it should be Structure getting called first, then Publisher.

0to9 Cross Creative Agency

Isn’t that odd though? That way structure uses unmodified (unsanitized) URL data? I’m also facing issues with the site_pages array not being translated for the site I’m in. Also only an issue in structure (resulting in untranslated nav items).

I realise I’ve got quite a frankensteinian install here and am not expecting you to waste your time debugging my highly unique situation, but had hoped you’d seen this before 😊

#10

BoldMinded (Brian)

What part of it is frankensteined? What makes it unique?

#11

0to9 Cross Creative Agency

Coming from EE2 with Publisher 1.7.5 (and Structure), worked fine then. Updated to EE3 with Publisher 2.7.3 (and Structure), worked fine then. Updated to EE4 with Publisher 2.9.0 (and Structure 4.3.24), suddenly stopped working. I meant coming from such a long way back with lots of old versions. I see all sorts of Publisher 1.7.5 extentions in my exp_extentions table.

Just not sure why it stopped working, and not sure if it’s the EE4 update or the 2.7.3 > 2.9.0 update. I might have to go check and see if EE4 on 2.7.3 provides the same results to be sure, but I’m supposed to deploy this to live in an hour

#12

BoldMinded (Brian)

Did you check the changelog of 2.9? First item:

[Refactored] The logic in the sessions_start, sessions_end, and core_boot has been consolidated mostly into core_boot, and simplified. Due to the nature of this change (a lot of important stuff happens here) we’ve decided to do a minor version bump to 2.9.0. Generally minor version bumps are for new features.

If you need to deploy your best bet may be to downgrade back to 2.8.3.

#13

0to9 Cross Creative Agency

Can I grab 2.8.3 somewhere?

#14

BoldMinded (Brian)

So to be clear, the Structure navigation tags and all the links within them are working fine, but just the {structure:page:*} variables are what are incorrect?

#15

BoldMinded (Brian)

Comment has been marked private.

#16

0to9 Cross Creative Agency

Link translations in Structure navigations aren’t working either. I see the English (default) label, but the link itself is correctly translated.

#17

0to9 Cross Creative Agency

Thanks. No dice on the downgrading either, same issues with 2.8.4. I’ll try 2.7.3, just out of interest.

#18

BoldMinded (Brian)

I just tested my local environment and the Structure nav tags are generating correct translations of titles and URL.

#19

0to9 Cross Creative Agency

It’s probably something else interfering. For sake of sanitation, can I remove all hooks for version 1.7.5 from my extensions table? I’ll do some more back-tracing on my own and stop wasting your time, but I’ll let you know if I find the cause.

#20

BoldMinded (Brian)

Yeah, if you have hooks with version 2.9 in them, and some with 1.7, then remove the old ones (backup your DB before doing any of this)

#21

0to9 Cross Creative Agency

Does this ring a bell?

Fatal error: Uncaught TypeError: Argument 5 passed to BoldMinded\Publisher\Service\Url\Url::__construct() must be an instance of BoldMinded\Publisher\Service\Template, instance of BoldMinded\Publisher\Service\Url\FileType given,

Get that when moving back to 2.9.0 from 2.7.3 after downgrade to that failed as well.

#22

0to9 Cross Creative Agency

Hm clearing cache and reuploading fixed this. I’ll be in touch.

#23

BoldMinded (Brian)

I’m seeing this now in one of my environments. I may have to undo some refactoring I did in the 2.9 release. I’ll post a new build when its ready.

#24

BoldMinded (Brian)

Comment has been marked private.

#25

BoldMinded (Brian)

This issue is fixed in 2.9.2