Closed petecooper closed 4 years ago
A patch is not hard but certainly not trivial to run by hand unless you're good with git. It just involves applying 3e2ce1fc and c61eb88d, but it's not comfy to tell users to do that. EDIT: @bloatware 's solution below, is better.
If you can find a suitable spot in the docs or the live site to shoehorn a "known issues" table, perhaps with PHP version and Txp version and maybe even links to patch commits so the brave can circumvent if they can't live with the notices, that might be the smart way to go. We can also document the yield
clash there, maybe? EDIT: And perhaps anything MySQlish too, like the password thing with MySQL 8?
Back-porting to a published release is not something we do, so we either release a 4.7.4 or (more likely) hurry along 4.8.0.
Distributing just updated constants.php
is probably the easiest option, though we have no special channel for 'partial' updates. I would like to avoid releasing 4.7.4 with just this file updated to avoid blocking txplib_misc.php
by some servers because of eval()
it contains.
Wasn't 4.8.0 meant to be a quicker release anyway? :)
What essential items are still needed for that release (that can't wait for 4.9.x). Yes our roadmap might change, but roadmaps do change.
So, practically, turning site mode to Live would be the best solution in real terms, and avoids a heap of work all round.
Edit: and @bloatware's take of dropping in constants.php
would be a close second.
Uhh yeah 4.8.0 was meant to be faster. The big question is: to custom fields or not to custom fields?
Back-porting to a published release is not something we do
Bad terminology on my part - I meant "do we back port to the 4.7.x branch", I can't English well today!
Uhh yeah 4.8.0 was meant to be faster. The big question is: to custom fields or not to custom fields?
IMHO: Release 4.8 without, bump everything else not done to 4.9 and move any 4.9 stuff to 4.10, etc. It doesn't mean that anything is delayed as custom fields are ready when they are ready, anyway.
We can release dev
as 4.7.4
, it seems finished enough and not very disruptive.
I'm good with Phil's suggestion.
The big question is: to custom fields or not to custom fields?
Defer to 4.9, though I'm not the one doing the work.
Also: releases = good.
No matter what has been left out (or half-done), there's new stuff in there already so it's all an improvement on 4.7.x
I'm fine with 4.8 too. But certainly without cf.
Please +1 (thumbs up), -1 (thumbs down) or comment.
Proposal (per https://github.com/textpattern/textpattern/issues/1430#issuecomment-559467788 from @philwareham): prepare to release dev
branch as Textpattern 4.8.0 RC1 or Beta1, without custom fields work.
There's background stuff to do in addition to just making the release, so if we can get into the right 'mode' that'll help everyone involved, I think.
Well, if we can somehow drop in new constants.php
, let's do it too. Releasing 4.8 could take a good month imo.
Releasing 4.8 could take a good month imo.
Christmas release! 😀🎄
I need to get some extra strings translated too I think - I'd need to check the latest issue requests.
We have strings to fix up, but a beta works for me, which gives us time to catch a few things and get a release out around Christmas maybe. I'd rather that than release 4.7.4 and then 4.8.0 hot on its heels, especially since the number of ISPs adopting PHP 7.4 in the first month of release is going to be pretty low.
EDIT: Phil beat me to it!
As a godless heathen, I am in favour of bringing some year-end cheer to the masses.
Let's roll. I'll start a 4.8.0 release issue so we can track.
Righto - I've got a busy December with Amazon, but I can squeeze in a few hours to help get the beta out the door.
I have a quiet-ish second half of Dec, so I can take up some Phil slack as needed (assuming you don't need my design skillz…).
Closing, will open 4.7.4 issue shortly. This was a wild ride!
Now that PHP 7.4 has landed properly, Textpattern 4.7.3 throws an error on both public and admin sides in Testing mode:
Deprecated: Function get_magic_quotes_gpc() is deprecated in /var/www/vhosts/textpattern.co/release-demo/live/textpattern/lib/constants.php on line 136
.Can a fix be backported to 4.7.3 to fix this error, or do we document how turn it off (change site mode, or edit code etc), or live with it, or something else?
I can see how a document outlining the step to switch to Live mode would be easily achieved, assuming the person encountering the issue is suitably privileged in a Textpattern sense, but I'd appreciate your take on this. Pinging @bloatware @Bloke @philwareham @jools-r for sanity check.