[wp-hackers] PHP compatibility
sojweb at indiana.edu
Sun Mar 29 02:43:39 GMT 2009
Oh, I know. The files aren't created as needed, they're modified if
they can be. That's all. Thing is, incompatibility problems are coming
regardless, and without simply dropping PHP 4 support (which is the
best solution), there will have to be a lot back-bending to get error
suppression and conditional code in. This could just sit on top of
that--it's not a solution, just an enhancement. It would be like Gears
in the admin: something that can be used, but doesn't need to be.
On Mar 28, 2009, at 4:29 PM, Otto wrote:
> Oh, sweet Jebus, no. Rewriting the PHP files on the fly? I can just
> imagine the incompatibility problems.
> Look, we still have problems on a lot of hosts writing files for
> plugin installation and for automated upgrades. If you start making it
> actually create files as needed, you'll break it in tons of places.
> So, until we can talk the-powers-that-commit into dropping PHP4, we're
> probably stuck with this backwards type of solution.
> Sent from: Memphis Tennessee United States.
> On Fri, Mar 27, 2009 at 9:46 AM, SoJ Web <sojweb at indiana.edu> wrote:
>> Just a thought about PHP and MySQL compatibility for the future.
>> There was
>> some talk on trac ticket 8701 about the deprecated warnings that
>> PHP 5 is
>> throwing about assigning the return value of new by reference, and
>> with PHP 5.3, magic quotes are deprecated, and in 6 will be removed
>> trac ticket 9394).
>> There was talk in 8701 about adjusting the error reporting levels
>> to account
>> for the warnings, but I think this not a suitable fix. If backwards
>> compatibility is to be maintained, there will only be more and more
>> of this
>> to deal with. Personally, I would branch off at this point with a
>> version of
>> WordPress for PHP < 5, and continue development requiring v5 or
>> higher. I
>> don't know that many would agree with me on that, though, so I have
>> It would be possible to read the user's configuration and rewrite
>> core files to accommodate, using a method rather like IE's
>> conditional code
>> we use for loading IE version specific CSS. Any time in the code
>> where there
>> is break with compatibility between versions of PHP, you could put in
>> conditional statements that would contain version appropriate code.
>> install (or update, or something similar), the file is read, the
>> checked, and the file rewritten with the conditions removed. If the
>> file is,
>> for whatever reason, not writable, it's just ignored, and acts as
>> it would
>> have otherwise.
>> I've implemented a rough functionality to this effect, and it works
>> well (files are attached here http://core.trac.wordpress.org/ticket/8701)
>> The conditions are only checked during install, but could
>> conceivably run as
>> an update any time the configuration changed (much as the DB update
>> runs with the schema changes). What I've implemented also checks
>> for MySQLi
>> functionality, as that is what I'm using on my server.
>> I realize this will complicate development, but complication in
>> some form is
>> unavoidable if backwards compatibility is to be maintained. Any
>> thoughts on
>> this approach?
>> -Jeff Johnson
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers