BoldMinded

All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

Please read about the changes to BoldMinded add-on licensing.

Ticket: Update to 1.0.8 ruins pages navigation in navEE

Status Resolved
Add-on / Version Publisher 1.0.8
Severity Critical
EE Version 2.5.2

Mike C

Sep 05, 2013

Hi Brian -

I had a Playa bug in Pub 1.0.3.3 and so decided to update to Pub 1.0.8. However, this seems to have created some serious issues in regards to navEE and site navigation via Pages (though it fixed our Playa issue). It’s done two things:

1. All of our non-primary navEE info is now gone. No translated nav titles are in there now (we had translated titles for everything).
2. The update seems to have seriously messed up how navEE sees page URIs. All page URIs in navEE are now just single segments. However, when looking at an actual entry, all segments as entered in the Page URI field are still present there. See these examples:

See CP entry: Content > Edit > Product > C5100 POS Battery Analyzer (page URI is: /products/cell-phone-battery-tester)
View the navEE node in the navEE settings: Developer > Modules > navEE > Primary Major > C5100 POS Battery Analyzer (edit)

The URI in navEE has only the last segment showing - and in fact, all page URIs in the navEE drop down only have their last segments showing.

Further, I’m not certain this issue is just navEE specific. I think it may be broader because I am unable to pull up the entry above using the Pages URI from the entry (http://staging.cadex.com/en/products/cell-phone-battery-tester) and can only access it when using only the last segment (http://staging.cadex.com/en/cell-phone-battery-tester).

This is a show-stopper for us at this point as our client was adding language info but I can’t have them continue incase we need to roll back to 1.0.3.3. Any attention you can bring to this asap is greatly appreciated.

Last note: I did not update the navEE publisher extension - I think we have the latest one at 1.4

Thanks,
Mike

#1

BoldMinded (Brian)

It looks like a resave of the entry fixed that page. What happens to other broken pages if you resave them?

#2

Mike C

Hmmm, ok but it seems like there’s still some weirdness going on. Look at the nav for this page while your language is German (although the same happens in English):

Mouseover: Produkte > Spectro-Schnelltester

The link does not have a language code prefixed. I found a few other pages like that and if I resaved them in navEE then the language code seems to show up properly.

I guess we can just resave all of these… How confident are you there isn’t a larger issue here?

Thanks, Mike

#3

BoldMinded (Brian)

Well, the 1.0.5 update script initiates a rebuild of the pages array, but its done outside of the entry save routine, and generally the Pages module can only save a uri when the entry is saved, so its possible that update routine has a bug in it. Backup the database and try saving a few more entries and see if everything seems to fix itself.

#4

Mike C

Ok - we’ll proceed as is for now, checking and updating things manually.

Can you leave this ticket open unit I get back to you? We’re going to do a bit of additional work next week and then we’ll recheck on how things are working.

Thanks, Mike

#5

Mike C

Hi Brain -

A further issue has come. Not certain it is related to the update to 1.0.8 but I’m adding is here as credentials are already in place in this ticket.

Our client ran into this issue:

As an ‘editor’ they are running into issue with the language drop down on the entry edit page not showing up anymore - and hence they cannot switch languages to edit other language versions. This just happened after the I did the following:

  1. Updated Pub to 1.0.8
  2. Added a new language (Korean)

Prior to this they were experiencing no such issues adding content for German.

I have looked through all the settings and cannot see any reason why they’d not be denied access to switching languages. FYI, super admins are fine - no issues there.

Thanks, Mike

#6

Mike C

BTW, I added a screen showing test editor credentials since there is no where else to enter extra credentials.

#7

BoldMinded (Brian)

Check the change log and the “can change language” setting. It was updated in 1.0.8 to not be member specific, but group specific.

#8

Mike C

Thanks - I guess I missed that.

I updated to 1.0.9 and noticed two issues (one minor just fyi and one more significant):

  1. The module still reports itself as 1.0.8
  2. That update seems to have played havoc with the navEE links for the primary language only. Go to the site (http://staging.cadex.com/en) and mouseover any of the drop down links and you’ll see a partial double URL (http://staging.cadex.com/en/http://staging.cadex.com/en/products/battery-analyzers). I cannot see anything obvious that would be causing this. The links are ok in non-primary languages.
#9

BoldMinded (Brian)

What do you have your site_url value set to? Full domain name or /?

#10

Mike C

It’s the full domain… it’s been that way all along.

#11

BoldMinded (Brian)

Mike, check it out now.

#12

Mike C

Thanks Brian - seems good now. Mind me asking what you tweaked incase we run into this again?

#13

BoldMinded (Brian)

I added a new method to clean up the URLs. In a section where it tries to prefix the language segment to existing segments it had the full site index as a segment. So it was prefixing the whole url as a new segment. I added this fix to my repo so it’ll be in the next release too.

#14

Mike C

ok - cool. Thanks.

#15

BoldMinded (Brian)

Mike, can I close this ticket?

Login to reply