[wp-hackers] PHP compatibility

[SoJ Web]

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.

-Jeff


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.
>
> -Otto
> 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  
>> then,
>> with PHP 5.3, magic quotes are deprecated, and in 6 will be removed  
>> (see
>> 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  
>> another
>> idea.
>>
>> It would be possible to read the user's configuration and rewrite  
>> certain
>> 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.  
>> During
>> install (or update, or something similar), the file is read, the  
>> conditions
>> 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  
>> pretty
>> 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  
>> wizard
>> 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
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers