Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Let's decide what's actually going into 4.6
Destry wrote #294396:
Putting some urgency on this topic again.
If we’re running out of time, it’s easy to backport that to the 4.5.x branch, although it will likely break plugins that use the old mysql functions directly instead of using the safe_ functions.
Offline
Re: Let's decide what's actually going into 4.6
ruud wrote #294397:
If we’re running out of time, it’s easy to backport that to the 4.5.x branch, although it will likely break plugins that use the old mysql functions directly instead of using the safe_ functions.
Is it unreasonable to expect plugins to be poked and prodded for a minor (as in major.minor.patch, so we’re clear) release?
Offline
Re: Let's decide what's actually going into 4.6
gaekwad wrote #294566:
Is it unreasonable to expect plugins to be poked and prodded for a minor (as in
major.minor.patch, so we’re clear) release?
Yes, I would consider that unreasonable. Unless said minor release is to fix a major vulnerability in the (core) plugin engine
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Let's decide what's actually going into 4.6
gaekwad wrote #294566:
Is it unreasonable to expect plugins to be poked and prodded for a minor (as in
major.minor.patch, so we’re clear) release?
I don’t understand what you’re asking… please explain.
Offline
Re: Let's decide what's actually going into 4.6
ruud wrote #294569:
I don’t understand what you’re asking… please explain.
My apologies, I was in a hurry when I replied.
My question again, with a few more helpful words: given that PHP 7 introduces a new raft of stuff and some folks will start to use it the day it’s released (or before), there’s a need to have Textpattern handle this new functionality with some grace instead of dumping errors and warnings to the browser. If the changes are to be merged into 4.6.0, which is a logical place, then this is considered a minor release in the Semantic Versioning approach of major.minor.patch — is it unreasonable to expect plugin authors to follow suit and upgrade their supported plugins to play nicely with PHP7? What’s the pecking order for Textpattern users? Do developers have more sway with the path Textpattern takes than, say, site administrators?
Many (?most) mainline hosts won’t have it on shared/managed hosting for at least a year. There will, inevitably, be the roll-your-own VPS crowd that jump on this before the year is out, but many more sites won’t touch PHP7 until it’s battle-tested in production for a year, two years or more. I’m running PHP 5.5.9 in production because that’s what Ubuntu apt-get gives me right now, and that’s great. I am not the only person in this scenario. I don’t envisage moving to PHP 7 in the next 18 months unless I need to, the same reason why when people ask me if they should upgrade to Windows 10 (because FREE) I advise them to hold off until the new year or next spring.
So yeah, it’s a thing that needs to be addressed, but my question really was if Textpattern is changing a bunch of internals for a minor release, is it unreasonable to expect plugin authors to do the same. I ask this as a administrator and user of Textpattern sites, not as a plugin author — and most importantly I’m asking nicely instead of being a grumpy antagonist.
Offline
Re: Let's decide what's actually going into 4.6
gaekwad wrote #294633:
… my question really was if Textpattern is changing a bunch of internals for a minor release, is it unreasonable to expect plugin authors to do the same.
Interesting question indeed. As a matter of fact, Textpattern 4.6-dev already incorporates a change which will affect some plugin authors: the need to programmatically register plugin-provided tags, or to live with nasty reminders in debug mode about not doing so.
Which arises the question: Is it sensible to package this into a minor release? What would an “administrator and user of Textpattern sites, not as a plugin author” expect?
Offline
Re: Let's decide what's actually going into 4.6
wet wrote #294635:
Which arises the question: Is it sensible to package this into a minor release? What would an “administrator and user of Textpattern sites, not as a plugin author” expect?
My perception is that Textpattern will look, feel and play largely the same on PHP 7 as it does now and PHP 5. Some of the internals will change, sure, but the majority of administrators won’t give that much thought.
Personally, and it’s not beyond the realms of possibility that I’m in a very small minority, I deliberately use as few plugins as possible on my Textpattern sites — not through any snarky or vindictive agenda, but because the number of plugin developers is relatively small, Textpattern does not appear to have a critical mass (currently) to attract and sustain new talent, and there’s nothing to stop anyone migrating to another project or simply taking the plugins down. As a small-c conservative administrator, this is something that I prefer to avoid if I can. But that’s just me.
I invest my time and effort in Textpattern core, and while I am amazed by what some plugin authors can achieve I personally think it unfair for me to rely on them for availability and support. To that end, I expect Textpattern to — broadly — keep up with the current general release versions of Apache, MySQL and PHP. That’s Apache httpd 2, MySQL Server 5 and PHP 5. If I have to wait for support for version x of library y on Textpattern z, then I’ll wait and hold back on upgrading. Textpattern doesn’t need PHP 7, and nor does anything else I expect to be running in the first half of 2016, so I’m sticking with PHP 5 for now.
If I wanted cutting-edge, I’d use Ghost on Node. If I wanted the world on a stick, I’d use Wordpress. If I wanted sleepless nights I’d use Drupal. If I knew how to code, I’d help out here more, but for some reason everything else continues to take a higher priority, sadly.
Offline
Re: Let's decide what's actually going into 4.6
The mysqli stuff shouldn’t break many plugins. Only those that call the PHP mysql functions directly instead of relying on the safe_* functions we’ve always recommended. I suspect that most plugins are NOT affected by this either because they don’t use SQL themselves or use TXP built-in functions to handle it.
Offline
Re: Let's decide what's actually going into 4.6
ruud wrote #294638:
The mysqli stuff shouldn’t break many plugins. Only those that call the PHP mysql functions directly instead of relying on the safe_* functions we’ve always recommended. I suspect that most plugins are NOT affected by this either because they don’t use SQL themselves or use TXP built-in functions to handle it.
What would be the “official” txp way to temporary connect to some exterior db, and then come back to txp db again (as in mysql_select_db($DB->db);)?
Offline
Re: Let's decide what's actually going into 4.6
There is no official way for that. In that situation you probably don’t use the safe_ functions for the second DB and use only PHP mysql_ functions (where you specify which DB link to use), so either you keep it as is or switch to using mysqli_ functions if your hosting setup requires it.
Offline
Re: Let's decide what's actually going into 4.6
ruud wrote #294644:
switch to using mysqli_ functions if your hosting setup requires it.
What should I replace global $DB; mysql_select_db($DB->db); with to make it both 4.5 and 4.6 compatible? It’s in a plugin, so hosting-independent.
Edit: could there be a safe_ function for this?
Last edited by etc (2015-09-10 12:08:21)
Offline
Re: Let's decide what's actually going into 4.6
ruud wrote #294638:
The mysqli stuff shouldn’t break many plugins.
This is pretty much what I’m getting at – it won’t be the end of days in Pluginland (it’s a place, really) if/when mysqli stuff is brought into play, but in the absence of a reasonably up-to-date or comprehensive list of all Textpattern plugins, supported or not, it’s an unknown quantity as to how many plugins will break. The high profile/active plugin developers around here will no doubt be on the case with modifications and updates as needed, which is encouraging, but other niche plugins might cause a problem.
How about this – make a mysqli-test branch on Textpattern with the mysqli stuff and then test it against the top twenty plugins from the most active threads in the plugin forum. A few testers could divvy up the work of the top twenty, report back, and then snag some more plugins as time/energy/motivation permits.
Offline