forbiddance of ini_set('include_path', ...) function causes fatal error at revision feature

Could use set_include_path() function instead.

Can you create a new file with <?php phpinfo();

and report what disable_functions setting has?

At the moment those functions are disabled: exec,passthru,system,shell_exec,proc_open,proc_get_status,proc_close,escapeshellcmd,es capeshellarg,ini_set,ini_restore

Perhaps set_include_path() would work here and if not, can show error message instead.

You have a typo in the message.

Use set_include_path() and restore_include_path() based off of r8483

Should probably return WP_Error() instead of a string. However, I'm not going to dig down into the wp-admin structure in order to make that work.

Replying to jacobsantos:

Should probably return WP_Error() instead of a string. However, I'm not going to dig down into the wp-admin structure in order to make that work.

Yes, was thinking to return WP_Error and change revision.php so it can handle errors.

Don't think a conditional is needed here. If a host has disabled set_include_path() why would they leave ini_set() enabled. Also what's the purpose of running restore_include_path() at this point? The include path may have been extended before wp_text_diff() was called and restoring it to default may break another function.

Good Points. Having a fall back is never a bad thing to have and with most instances, the first conditional will evaluate to true. For edge cases where ini_set() is enabled, but set_include_path() is disabled. It seems unlikely, but available.

I don't like error suppression, because you really don't gain anything from it, the error will still be passed to either the Apache error log, so no benefit from that. Also before PHP 5.2, it is quite the performance hit.

If you want to remove restore_include_path() then it is possible. I had it because it already exists within the function. If it currently works, then there is no harm, but there is no harm in keeping it either.

This should be in the wp-settings.php. It should create a constant named WP_INCLUDE_PATH_DISABLED, in which case, the include path appears to be set each time the function is called. If it is called once, then no big deal, if it is called 20 times, then the include path is set and then restored 20 times. This adds overhead to the process. It is better to do it once outside of the function.

I don't understand the strict order "not modify affected files". These files original comes from Pear Framework and are just a copy out of to be present at WP. So WP may maintain now these copies as the would be part of the product itself. In this case, these files can be modified to required the needed other ones by using the correct path an not be dependend of other ini manipulation function potential disabled by hoster too. Doing so, not further errors will occure here. The alternative would be to define WP needs PHP5 (at some hoster it doesn't run any longer with PHP4, i proofed this!) and the classes will be loaded by autoload feature of PHP. Why working around several better ways fo just keeping this few files as is ?

Replying to codestyling:

I don't understand the strict order "not modify affected files".

The reason is that when you go to upgrade, you have to keep making those modifications again, and again. This is not ideal.

What is needed for the patch?

Patch for trunk (r8561) sets the include path in wp-settings if Revisions aren't disabled.

Can you check the new patch and see if it is acceptable?

Set include path in wp-settings for 2.6 r8561

Patch for 2.6 also.

Fixed in [8562] and [8563].

Reverted... Patch throws a fatal error.

7391.r8579: codestyling's changes as a diff.

(In [8581]) Fix Text/Diff includes. Props codestyling. fixes #7391 for trunk

(In [8582]) Fix Text/Diff includes. Props codestyling. fixes #7391 for 2.6