Thread

Hello,

Very strange. After upgrading today, it seems my {redirect} variables are all going to SITE_INDEX. Here’s the setup:

In my template:

{redirect="{embed:template_group}/{url_title}"}

The argument ($str) passed to extract_path() in Functions.php:

=about/the-madeup-entry

It doesn’t hit the conditional that follows (Line 299 in Functions.php) because of the Regex:

preg_match("#=(.*)".RD."#", $str, $match)

It’s looking for the string to end with a trailing “}” so it defaults to “SITE_INDEX” which is incorrect. Modifying the regex to be this:

preg_match("#=(.*)#", $str, $match)

Causes it to work, but this particular function is used in a lot of places and I’m worried that the “RD” part was there for a reason. Can you offer any insight on why it’s wanting a trailing bracket in this function?

A quick echo of all arguments that this function was passed in one page load (down to my redirect) showed that none of them actually had trailing brackets:

url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="visit"
url_title_path="calendar-exhibitions"
url_title_path="calendar-exhibitions"
url_title_path="calendar-exhibitions"
url_title_path="calendar-exhibitions"
url_title_path="join-support"
url_title_path="join-support"
url_title_path="join-support"
url_title_path="join-support"
url_title_path="join-support"
url_title_path="join-support"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="learn"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="community"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
url_title_path="about"
=about/the-madeup-entry

So I’m wondering if this is a bug?

Thanks!

Jesse

Not working for me either!

I just ran into this too with “url_title_path=” and “title_permalink=”

I found where it is broken.

/system/expressionengine/libraries/Functions.php

line 296

      if (preg_match(”#=(.*)”.RD.”#”, $str, $match))

This is breaking it

This will fix it:

      if (preg_match(”#=(.*)#”, $str, $match))

But not sure if it will break anything else.

Brad

I found where it is broken.

/system/expressionengine/libraries/Functions.php

line 296

      if (preg_match(”#=(.*)”.RD.”#”, $str, $match))

This is breaking it

This will fix it:

      if (preg_match(”#=(.*)#”, $str, $match))

But not sure if it will break anything else.

Brad

Brad,

Looks like you found it. 😊

This fix did work for me.

I was also getting broken links from url_title_path=‘stories/work’ after upgrading from 2.1.3 to 2.2.0 - the link cuts out the stories/work part of the URL.

Thanks for the Bug report - a hotfix went in tonight.  It’s almost identical to Brad’s fix, but I’d recommend downloading a fresh copy and replacing system/expressionengine/libraries/functions.php with a fresh copy.  Or- add this bit as well as tweaking the preg:

$match[1] = trim($match[1], '}');

as per the bug thread.

Robin, I’m very glad you could get a patched version out, and particularly appreciating as this is midnight oil for you where you are especially.

I just would so wish you guys wouldn’t put out new versions of the downloads without marking them clearly with a code so we can tell the difference. Version is version, build is a date, so I guess it needs to be an additional code.

Hotfix code, an hf+number attached to the build? Something, please….

For now, a good rest to you, deserved.

Best,
Clive

Yes, I’m rolling back my install due to some additional issues with my install post-upgrade and second Clive’s request.

Thanks for the work.

Bruce

Yep- we had 3 hotfixes go in yesterday (day of release is cutoff for hotfix)- and that makes build date not particularly useful.  At the moment, I’m advocating a ‘Hotfix’ post to the Release forum at the end of the cutoff- list any files changed by a hotfix at the time of posting (which would be the last of them) or note ‘No hotfixes’.

That’s not firmed up yet, but I’m leaning that way.  Might be least confusing?  I do like the ability to hotfix rather than release a new version and require running through the update.  (We’ve eliminated build releases to reduce updating confusion.)

Robin, what other files were affected by the hotfix?  I only replaced the /libraries/Functions.php file, is that enough?

Thanks!

One was moot if you successfully upgraded- ud_2.2.0 had an issue if comments weren’t installed.
One was also fairly obscure- ie8 I believe had an issue with rounded corners [removed]
/system/expressionengine/controllers/cp/javascript.php
themes/javascript/compressed/cp/publish.js

And then the functions.php library, of course.

Awesome, thanks again!

At the moment, I’m advocating a ‘Hotfix’ post to the Release forum at the end of the cutoff- list any files changed by a hotfix at the time of posting (which would be the last of them) or note ‘No hotfixes’.

I think that would work, Robin, being sympathetic to the transitions you guys are making from ‘old ways’.

I’m weighing the ‘enterprise’ aspect of things that you want to mark in your future, having once participated fairly firmly there, as un-self-marked changes still go against ‘the rules’, which have been there for good reasons.

Yet reality is that (pre-)release to community, and response to what it finds is a true and important part of the EE quality control ecology. I suspect it will always have to be so, due to the shifting nature of web components, and the degree of actual complexity that EE lets people mostly ignore, to go on and build the sites that they’d like, relatively easily.

Also, I think real enterprise people will recognize and appreciate this. They’ll do so much more readily given the new Ellis approach to tieing down assurance for all the quality you can internally, to include intentional regression testing to the degree that catches things like this busted pathed variables ability before they get into the wild, including interactions with popular add-ons. Then only the ‘oops, that browser’s odd corner’ or ‘that thing they did in that short-lived PHP release’ sort of matter will be there to net you.

I’m making some words here, because I think it is a matter of degree. Get the degree high enough, and Ellis as a company can talk intelligently of release phases. Maybe three of them?

I.e., it’s good to go when we ship it—I feel you are really closing on this claim. Initial release discovery period (1 week?) then is something we sensibly plan on, and ‘you can see’ we respond very rapidly in getting these teething problems cleared, with history showing releases are stable after that. Following this response to community, the release is in its ‘enterprise’ quality phase, and we stand behind that quality level.

Something like that. And then those ‘enterprise’ recipients or anyone else who likes to participate in the community which good complex software lives in these days can put pre-enterprise releases on their staging server. Both they and those who wait for the shake-out to complete—and the release be marked so by Ellis—will be able to feel they are operating in a comfortable envelope, without any questions as to whether the situation is a dependable one.

Ok, my wake-up piece for the day, in the way of suggestions. Please forward where you think it will do the most good, Robin, and congrats on all you guys have accomplished to bring 2.2.  It’s worked for me already on two separate site tests, and it’s going up to be live as we speak.

Best,
Clive

Just a quick further thought, as I realized the point of view most operating in here, and that maybe helpful also.

It’s that experienced and enterprise people (definitely as you’ll find not always the same) will be very interested in process—substantial process. The better ones will be interested in intelligent process.

I think you can answer on both counts, in a frame as above:

- You have been constructing and are consistently improving a substantial quality process for the builds themselves. The evident path forward on this is ever improving the scope of regression and platform testing (server/database software and browsers).

- You (will) have a very fitting, staged community process, which both embraces and benefits from the realities of the ever-changing web world.

The key here is realism. No-one sensible believes you can make things perfectly; they just don’t want to feel disappointed, that they received less than the best known types of effort. Process lets them see that; and then comfort is there. There is a solid foundation. Everyone can go forward.

When the inevitable happens—then, your Ellis quick-response skills come to the fore. Advantage 3.

Ok, I have a bus to catch, and this was quick. Mercifully and properly so 😉

C.