Errors in view files if short tags are off

Hi Jack,

Is this just a problem with people using Structure or do they still have the problems if they disable Structure on their install?

Also is this a certain version of ExpressionEngine that is exhibiting this or all versions and do you have any information on their server types etc…?

Thanks,

Mark

Not sure about that, but it’s at least the Structure view files with issues, which is still odd enough in and of itself…

I had thought it was just 2.3.x, but just had a report of 2.2.1 also. Getting more detailed server info, will post shortly.

They DO get this error until short tags are on though:

I was one of the first to catch this Structure bug, and have done some further testing to shed some light on how and when this error occurs:

Parse error: syntax error, unexpected T_ENDFOREACH in /system/codeigniter/system/core/Loader.php(727) : eval()'d code on line 116

The error occurs:

* When [b]short_open_tag: off[/b] in [b]php.ini[/b]*
* When there is one or more Structure pages in the database
* Only when viewing the "Pages" section in Structure

I confirmed this behavior on EE 2.1.3, EE 2.2.2 and EE 2.3.0, all using Structure 3.1.2.

Strangely, even with short_tags: off in php.ini, the error is not present on a fresh install of EE after enabling the Structure Module. It’s only after a “page” is added to Structure that the error appears. Changing short_tags: on in php.ini does not fix the problem.

Worse yet, this behavior seems to contradict an upgraded Structure installation. Changing short_tags: on in php.ini does fix the problem!

It’s too difficult to determine if PHP, ExpressionEngine or Structure is the problem.

However, it’s been recommended for several years to not use the short tag “short cut” and instead to use the full <?php and ?> tag combination.

Would it be too preposterous to debug the problem in Structure by replacing all of the short tags with the full, proper PHP opening and closing tags?

It’s been recommended for several years to not use the short tag “short cut” and instead to use the full <?php and ?> tag combination.

This is true except in the case of view files, especially in CodeIgniter/ExpressionEngine where they are rewritten on the fly if they’re not supported by the server. This error shouldn’t be occurring, but it is.

I tracked it down to the following line:

<?php if($permissions['reorder'] === FALSE):?> page-handle-disabled<? endif; ?>

The error is resolved when converted to:

<?php if($permissions['reorder'] === FALSE) echo " page-handle-disabled";?>

Any idea why that particular syntax would throw an error? Unless i’m really blind, it’s perfectly legitimate code.

I can confirm that the error goes away with this single line code change:

<?php if($permissions['reorder'] === FALSE) echo " page-handle-disabled"; ?>

I verified this with short_open_tag = on and short_open_tag = off.

I’m committing this to the codebase and it’ll be present in the next bugfix release (later today or first thing tomorrow), but it still begs the question why it was an issue in the first place.

Hi Jack,

As this concerns Structure then it’s not really something we can give support for here.

I’m therefore going to move this over to the Development and Programming forums for you but will ask internally on this one incase anyone can comment on this.

Thanks,

Mark

Thanks Mark. Moving it isn’t quite right though… The real problem at hand is why ExpressionEngine choked on converting standard shorthand syntax and spat out an error, instead of string replacing it. The “fix” is a workaround, the problem (which I believe to be a bug), still exists.

It seems whenever the name of a third_party add-on is in play, the first instinct is to immediately remove responsibility without digging further. The add-on development API is in-play, which is an EllisLab supported area of code. Just saying. I’d add a smiley face to let you know I’m not upset, but it would reduce the emphasis i’m trying to make, even though it’s true. Thanks for all you do Mark.

Hi Jack,

It seems whenever the name of a third_party add-on is in play, the first instinct is to immediately remove responsibility without digging further.

Sorry that it seemed this way. I can assure you that was not my intention at all.

I may have misunderstood exactly what is wrong here so I’ve asked internally on this one to get some feedback for you.

I’m not able to move this forum thread back now due to not having enough privileges but if whoever comments decides it should be moved back then I will be able to get someone with more forum privileges than me to move it back for you.

The add-on development API is in-play, which is an EllisLab supported area of code. Just saying. I’d add a smiley face to let you know I’m not upset, but it would reduce the emphasis i’m trying to make, even though it’s true. Thanks for all you do Mark.

No problems. I guess my error in all of this was that I was thinking that other add-ons have never had this problem before so it isn’t ExpressionEngine to fault here.

I may very well be wrong on that though and if so then I totally apologise.

Hopefully one of my colleagues will pop in here shortly to confirm either way though.

Thanks,

Mark

Thanks for being on it Mark. I agree it’s odd, but that one line breaks every time unless it’s rewritten to avoid short tag syntax. At this point, the error has been “resolved”, but I think it’s worth pursuing to see if there’s a use case in play here triggering a parse error in the rewrite engine.

Our convention is to use the short echo and control statements, but the full opening tag. If you do:

<?php if($permissions['reorder'] === FALSE):?> page-handle-disabled<?php endif; ?>

Does that solve the error? I’m expecting it would.

That said, I did double check w/Pascal trying to figure out if it was just a convention or a CI requirement- CI docs suggest using:

PHPs alternative syntax for control structures and short tag echo statements

Note- they didn’t specifically address opening tags. Pascal said opening tags were discouraged but he was thinking they were supported (checked- that changed in like ‘07). Looking at it, neither of us could spot that being the case.

So- I have left that decision is his competent hands. I believe the EE standard will continue to be use it for echos and control structures in views, but stick with full opening tags. And just checked the docs, they’re consistent w/CI in advocating the echo/controlS and not mentioning opening tag. May need an explicit mention if it’s causing issues, though.

And boy- this will be an excessively long reply if switching to <?php doesn’t actually solve the problem. 😉

Well I’ll be, you’re spot on. That certainly was the fix. I’m delighted to know it stayed within consistency, and thanks for the persistance! Now to figure out if i thought that was truely correct syntax, or if it missed it in a sea of <?= $these ?>. Ah, PHP 😊