[moderater note: the following posts were removed from 'if you are getting blank page with Atahualpa 3.6.x (Suhosin issue)' since they are a discussion about the merits of the way the theme is written, and have no bearing on solving the Suhson issue for the existing version - ie it's all off topic]

When I refer to the 'server' I mean all the software: the server itself (Apache, Windoes etc), PHP, MySql. Just those three, with all there options, gives an unimaginable number of permutations that are not under any theme's control...

Sorry but I have to raise a slight issue with the following reasoning:

The problem is not with the Atahaulpa theme.
The problem is with the server variables.

Yes there are many 'server variables not under any theme's control' but generally (and in most cases) they are compatible which each other and the stuff that relies on them such as a theme.

If this wasn't the case the web would come to a grinding halt.

If a theme is so dependant on the server environment, then this must raise serious questions on the stability of any Wordpress based site.

I think the problem is with Atahaulpa, which is a shame.

Other themes don't allow you to include custom PHP code through the theme options. They don't have the issues because they don't have the feature.

Custom PHP code worked fine in Atahualpa as long as "Eval" was allowed in themes, which it isn't anymore.

I had to look for a replacement for Eval to keep the feature and found it in stream wrappers. Admittedly I didn't know that Suhosin would pretty much make it impossible to use stream wrappers if the user doesn't have access to the PHP config. After all, stream wrappers are a core PHP feature, Suhosin is not.

That being said, this will be fixed, by removing this feature (to add executable PHP code through the theme options) altogether.

Thanks for this explanation - it is now much clearer to me.
Atahaulpa is a great theme - long may it continue.

...and finally, I am dying of curiosity...who ever came up with the idiotic name of Suhosin?
Sounds like an Asian sauce you would put on prawns or something.

And if I have insulted anyone, I am very sorry!

Oh God. Me and my big mouth. Sorry if I offended you. Who knew that a blank page would be called after a guardian angel? I stand corrected.

The blank page is a result of the Suhosin patch being installed on SOME hosts and in SOME environments.

You DID NOT offend anyone. We are just having fun.

Originally Posted by metapete

I think the problem is with Atahaulpa, which is a shame.

I agree with metapete on this one. Obviously Wordpress chose to ban eval() because of security issues. Then Atahualpa did not comply and instead looked for a workaround. Hence still compromising security and still going against Wordpress' will to harden the whole system.

The workaround, using stream wrapper, raises new issues when used in "high level of security" environment. That shouldn't surprise anyone as basically nothing changed, the theme still does potentially dangerous actions (but a slightly different way).

The only proper solution to this is to fully accept Wordpress' will and remove the feature as we know it. (or just go against their will to please users and to not change something which was not broken in the first place)

Btw, I would be interested to read where Wordpress explained their choice to remove support of eval() and technical solution to do this. Anyone got a link ?

PowerKiKi - see post #96

you have to ask yourself, why don't they ban plugins that use eval()?? (widget logic, exec-php...)

I don't think it is a Atahualpa problem. When I run my site on my own server (Vertrigo) everything works fine. When I move the same site to my host provider, I got a blank page. Did the fix regarding Suhosin mentioned earlier in this thread and the problem went away.

Originally Posted by PowerKiKi

I agree with metapete on this one. Obviously Wordpress chose to ban eval() because of security issues. Then Atahualpa did not comply and instead looked for a workaround. Hence still compromising security and still going against Wordpress' will to harden the whole system.

The workaround, using stream wrapper, raises new issues when used in "high level of security" environment. That shouldn't surprise anyone as basically nothing changed, the theme still does potentially dangerous actions (but a slightly different way).

The only proper solution to this is to fully accept Wordpress' will and remove the feature as we know it. (or just go against their will to please users and to not change something which was not broken in the first place)

Btw, I would be interested to read where Wordpress explained their choice to remove support of eval() and technical solution to do this. Anyone got a link ?

Not sure where you got the idea from that Atahualpa would "not comply" or do "potentially dangerous actions".

Atahualpa is the most downloaded theme on wordpress.org, and most likely the one with the most active installations right now. The code was looked through by numerous persons in the past years, from automattic, from wordpress.org. It went through dozens of reviews including some very in-depth ones.

If all this doesn't ring a bell, don't you think that Wordpress would take Atahualpa off the list on wordpress.org if it was doing "potential dangerous actions"?

This eval/stream wrapper issue has nothing to do with Atahualpa specifically, these formerly permitted (standard) PHP features were now globally removed by Wordpress, for all themes, along with other PHP functions, leading to a situation where themes are more limited in what they can do inside WordPress.

The WordPress team did probably not discover these PHP functions just now, it's that they made the decision that from now on themes can live with a more restricted feature set and be forced to align more closely to a particular philosophy how a theme must be structured, what features it can have, etc...

Theoretically this should result in better overall compatibility between WP/Themes/Plugins, and in better upgrade compatibility. It should also make it easier for the new voluntary review team to check themes.

Disallowing eval is easier than looking through all themes whether eval is used in a malicious way or not. However all this does of course put a burden on more advanced themes like Atahualpa to either find new ways to implement their features or to drop the feature altogether.

I agree there is a debate on "should we ban dangerous function ? why and how ?". But this is not the point. According to Flynn, that discussion already happened within Wordpress's team and they decided for us.

The issue is that Atahualpa pretend to agree with them, yet it doesn't. The whole operation is about hardened security. If BytesForAll agree with Wordpress' point of view, Atahualpa should drop the feature. Otherwise just don't do anything. But trying to "hide" security issues under several layers of code and "complex" mechanics is not a wise thing to do IMHO. It's digging a hole to fill another one.

But again, I would really like to read what Wordpress said about that. Do you, or anyone else, have a link to a reference ? googling this didn't get me anything...

Flynn,

by "potentially dangerous actions", I meant eval() code which was not written by theme's authors.

Why Wordpress decided to ban eval() ?
I bet it is because eval() can be used to execute arbitrary code, which was not written by theme's authors (or crypted code via base64_decode()).

Am I wrong ? Is there another thing I am not aware of about eval() usage ?

One of Atahualpa strength is specifically to execute code written by the end-user. By definition it's going against new Wordpress rules (as long as I am not mistaken on the reason of this ban).

Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?

Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?

Yes that is exactly what they do, if a theme uses eval() it is automatically rejected.

Originally Posted by PowerKiKi

Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?

Yes, exactly. Theme Guidelines. There is a Theme Check Plugin that incorporates most of the automated checks.

See also Theme Reviewers Mailing List in the thread "Alternatives to eval()".

Even a version of the P2 theme from Automattic, used for internal blogs on wordpress.org, got rejected because of an eval.

The Atahualpa developers then found a way to circumvent this restriction. This was clever, but then the Suhosin issue arrived. Looks like a nightmare to me.

Point is: It's not considered safe to allow input from theme option fields to be executed as raw PHP code.

My advice would be to extend the Atahualpa substitution variables with new ones for the name of the blog, the different URL paths on so on, until most needs are satisfied.

The next version, if released without the ability to enter PHP code in options, could detect all PHP code and nag the user to remove this, while suggesting some substitution variables.

Thanks for your input Knut Sparhell, it was an interesting read !

At first I thought "let's not listen to Wordpress guidelines and keep the eval()", but then I realized I really don't want Wordpress to end up like Typo3. Splitting code between file and database is a nightmare for maintenance. I much prefer use child-themes or plugins, as suggested in the thread mentioned. At least you know where to look for bug: one single location, the files, which can be versioned.

Again, I firmly believe Wordpress didn't say "don't use this specific eval() function", but rather "don't let arbitrary code be executed". And the links provided by Knut seems to confirm that opinion.

I agree with Knut's advice about adding new Atahualpa substitution variables to "replace" PHP execution feature.

Substitution with variables will be the way to keep the dynamic nature of Atahualpa

Not as dynamic (any PHP code, no limits) as it used to be but not that bad either.

Instead of being able to use all existing PHP functions plus any IF/ELSE logic etc., only a much, much smaller set of predefined, known PHP functions, without loops or other logic, can be used in the future, and Atahualpa's predefined variables

The still usable PHP would be parsed as text and translated into executing PHP
A working parser is already in 3.6.7, to make custom widget areas work. It works with code of the type:

<?php function_name('parameter1=Parameter 1&parameter2=Parameter 2'); ?>

I will implement something along these lines for other functions to bring back some of the custom PHP code functionality.

One possibility to still have full PHP access would be to create custom widget areas in Atahualpa (bfa_widget_areas(...) works) and then put the PHP code widget into those areas. The PHP code widget like all plugins apparently is still allowed to use "Eval". The question is whether WP will keep allowing Eval in plugins. A fresh copy of the PHP code widget should work for a long time, though. It is a small plugin.

Have you considered building hooks into the theme? That would allow users who need PHP execution to enable it either through a plug-in or by adding a function to functions.php.

Just a thought.

-Brad

I would strongly advise against implementing a parser in a theme. Parser are not small tasks and I really don't see the point to re-invent something which already exists and which will be much more limited (by design).

BradBrown's suggestion is really the way I would go. Let the coders code in files, not in forms.

The beauty of allowing php in the theme options is that the user doesn't have to recoded changes to any theme files each time there is an upgrade.

The argument that users should might make an error in a theme option so they should only make the change in a php file is, in my humble opinion, ridiculous. More support issues will occur if they change the theme files and six months later do an automatic upgrade which wipes out the existing code, and suddenly their changes are gone. And you know they won't have made a backup or written down what they did, human nature being what it is.

Besides, that method will also cost them time/money having to redo the work again and again.

I agree that eval(), with encrypted arguments, should not be allowed. However, I think using eval() to parse a theme option THAT THE USER codes, should be allowed and WordPress has done a disservice to the community.

The problem of upgrading themes you describe is exactly what child themes are for. A clean (and easy) way to modify themes while still allowing easy upgrade.

http://codex.wordpress.org/Child_Themes

If you make a child theme and change function.php or any of the other files and the next upgrade of the theme upgradesthe module you changed, you still have to go back and make a new copy and add your changes back in. I really wouldn't call this a 'clean' process.

plus, the power of Atahualpa is that you have so many theme options to change the CSS. If it was all hardcoded in style.css you couldn't do this.

So in a typical theme, yes child themes are the way to go, because it's the only way to keep things across upgrades (unless sthe module you changed changes) but with Atahualpa, you don't need to change the theme code to create a new look and feel and the changes you make are in the database so you don't have to worry about upgrade issues.

While both methods work, I think Atahualpa is much easier.