Install do not check the magic_quote_sybase status

[wpmuguru]

MU Trac Ticket: ​http://mu.trac.wordpress.org/ticket/981

Just try to install on a server that it's magic_quote_sybase is on (okay for Oracle, but fatal for mysql) . It failed to update the wp-config.php and didn't set correctly the .htaccess.

[wpmuguru]

Is this an issue with the WP install as well?

[ryan]

Both WP and WPMU force it off at the beginning of wp-settings.php. If the reporter means setup-config.php, I think it does not get the ini_set for magic_quote_sybase since it doesn't include wp-load.php

[nacin]

Needs patch, I guess.

[wonderboymusic]

Is this still relevant? From php.net:

This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

[wonderboymusic]

Related: #19455, #18549, #18322

[dd32]

Given the configuration is deprecated, and removed in 5.4, and we haven't supported this in 9 years of WordPress, I really do not see a need to add this.

[nacin]

We already handle sysbase in wp-settings (see #19455) so we might as well support it here.

[chownd]

disables magic_quotes_sybase in setup-config.php

[SergeyBiryukov]

Could you please attach an SVN patch rather than a PHP file?

See ​http://make.wordpress.org/core/handbook/submitting-a-patch/.

[egill]

Replying to SergeyBiryukov:

Could you please attach an SVN patch rather than a PHP file?

See ​http://make.wordpress.org/core/handbook/submitting-a-patch/.

Not trying to steel anyones thunder, was bored, created an SVN patch (ignored unrelated changes in the file).

[chownd]

Replying to egill:

Replying to SergeyBiryukov:

Could you please attach an SVN patch rather than a PHP file?

See ​http://make.wordpress.org/core/handbook/submitting-a-patch/.

Not trying to steel anyones thunder, was bored, created an SVN patch (ignored unrelated changes in the file).

Thanks. I'm still trying to learn how to do that.

[maxzeroedge]

Replying to egill:

Replying to SergeyBiryukov:

Could you please attach an SVN patch rather than a PHP file?

See ​http://make.wordpress.org/core/handbook/submitting-a-patch/.

Not trying to steel anyones thunder, was bored, created an SVN patch (ignored unrelated changes in the file).

Wouldn't suppressing the error in ini_set bring up troubles if it couldn't set? Instead we could check if it is active and then disable it?

[egill]

Replying to maxzeroedge:

Wouldn't suppressing the error in ini_set bring up troubles if it couldn't set? Instead we could check if it is active and then disable it?

You're right (I should have paid a bit more attention creating the previous patch), thanks for the suggestion. Uploaded a new patch:
https://core.trac.wordpress.org/attachment/ticket/12031/12031.2.patch

[nacin]

Replying to egill:

Replying to maxzeroedge:

Wouldn't suppressing the error in ini_set bring up troubles if it couldn't set? Instead we could check if it is active and then disable it?

You're right (I should have paid a bit more attention creating the previous patch), thanks for the suggestion. Uploaded a new patch:
https://core.trac.wordpress.org/attachment/ticket/12031/12031.2.patch

I think we error suppress ini_set() for when the function might end up in disabled_functions by annoying hosts. I would just copy exactly what we do in wp-settings.php, so the first patch.

However, and I'm sorry for the 'bad' news for those who worked on this ticket in the last few months, but this was fixed incidentally in 4.0, as setup-config.php now loads wp-settings.php. See #28740, [28978].

Good news is, we just retroactively increased our fixed bugs count for 4.0 by one.

Thanks all. :)