Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern's ongoing development
philwareham wrote #342181:
I have now created 4.9.x branches on the Textpacks and themes
And I’ve updated the build scripts in the 4.9.x dev repo to fetch content from the 4.9.x branches (hopefully). Please test.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern's ongoing development
Just updated my repo clones and lots of commits (partly due to year number changes, I guess). Am I right in assuming that the dev branch now has the new custom_fields incorporated in it?
TXP Builders – finely-crafted code, design and txp
Offline
Re: Textpattern's ongoing development
jakob wrote #342218:
partly due to year number changes, I guess.
Mostly that!
Am I right in assuming that the
devbranch now has the new custom_fields incorporated in it?
That’s correct. The custom-fields branch is defunct. I’m only keeping it around because I had to do a big merge commit to bring CF into dev, and some of the changes weren’t at all clean. In one file, for example, git had amalgamated two different merges and left half of the old dev one in its suggestion, along with some crufty old code that would have broken the branch if I’d committed it as-is. So I had to unpick that manually and write what I think is the correct code. But now I’m concerned it might have done a bad job of other files and convinced itself it did the right thing and told me they were cleanly merged.
When it’s been verified to work (my CF installation is mashed so I’m gonna have to start from scratch) we can get rid of the cf branch.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
#28 Today 00:34:53
Re: Textpattern's ongoing development
I was pleasantly surprised that my local test site that has live on dev like forever happily upgraded to 5.0.0-dev. It lost all its article custom fields (glz_custom_fields, thank you and have a nice rest) but that is about it. So far. My images CF (jcr_image_custom) worked out of the box. I did a quick rebuild (recreation) of a couple of the CFs I had and the output worked as expected on the front-end. I am sure there still are tons of issues hiding under the leaves though.
That makes me happy as I then have a serious real-world-looking testbed rather than a near empty shell to play along. The only other visible issue: that persistent message that I had upgrade to 5.0-dev. A trip to the DB editor and the prefs table fixed that.
I had of course made a backup of the whole thing before proceeding, and I’ll use that with 4.9.x for daily testing needs.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
#29 Today 08:39:19
Re: Textpattern's ongoing development
phiw13 wrote #342220:
It lost all its article custom fields (glz_custom_fields, thank you and have a nice rest) but that is about it. So far. My images CF (jcr_image_custom) worked out of the box. I did a quick rebuild (recreation) of a couple of the CFs I had and the output worked as expected on the front-end.
I’ve not been following the custom_field branch so actively, and a couple of months back things seemed to still be in flux with the structure of the entities (and maybe also the other content-type panels), so there is, as yet, no conversion for glz_cf or any of my other content-type custom field plugins. I don’t think the devs have tackled that either. glz_cf uses the regular custom fields for the actual content, so you’re likely to have most luck with that, but you won’t get any of the custom field options content ported over (e.g. for radios, checkboxes, selects etc.).
The loose idea is that in future there’ll be a one-time conversion routine to the new structure, and then the plugins become obsolete. The new custom fields offer more flexibility and other data storage types (currently all cfs are just text fields) so there will likely be some manual post-adjustment necessary.
TXP Builders – finely-crafted code, design and txp
Offline
#30 Today 08:44:29
Re: Textpattern's ongoing development
jakob wrote #342218:
Am I right in assuming that the
devbranch now has the new custom_fields incorporated in it?
Bloke wrote #342219:
That’s correct.
Thanks for confirming. I’ll probably switch to 4.9.x for current work, then. I guess it’s likely that 5.0.0 dev will have more flux than the dev branch has had recently.
TXP Builders – finely-crafted code, design and txp
Offline
#31 Today 08:54:07
Re: Textpattern's ongoing development
jakob wrote #342221:
[…] so there is, as yet, no conversion for glz_cf or any of my other content-type custom field plugins. I don’t think the devs have tackled that either. […]
Yes, I know that, and I did not expect those glz_CF to work at all. I just pointed out that as far as my content is concerned, nearly everything got ported over as correctly. It actually surprised me a little that jcr_images_custom works (possibly because it is a more recent / modern code and only of the type text).
Anyway, things work surprisingly well so far, compare to a few months back.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
#32 Today 09:28:52
Re: Textpattern's ongoing development
phiw13 wrote #342220:
I was pleasantly surprised that my local test site… happily upgraded to 5.0.0-dev.
Yay. I’m pleased that worked… mostly. Even though 5.0 is going to be a big departure, there’s no point completely shutting out people’s existing sites from an upgrade viewpoint, so we will take as many steps as possible to assist migration.
It lost all its article custom fields (glz_cf).
The plan, as Jools says, is to have it seamlessly migrate text-based fields natively, whether they’re part of the 10 core or the glz_cf extensions. However, those of other types like select lists, date pickers and checkbox sets won’t be migrated by core directly.
Instead, when the new DB structure and way of working stabilises more, one of us will write a conversion utility to migrate these “other” types to Txp 5.0.0 parlance. This will need to be run prior to upgrading. But the challenge here is that the new DB structure won’t be available at that point of the upgrade process.
So, my initial thinking is that this tool will simply prepare a “backup” of your CF data and definitions into an .xml file or two (most likely, or possibly JSON).
With the file(s) in place in your installation, when you upgrade, the end of the _to_5.0.0.php script will check for their existence and run our standard ImportXML() on them, thus recreating all the non-varchar field data and options. Transmit users will need to ensure they don’t accidentally blat the XML file(s) if they do transfer new files that way (I believe its default operation is still Replace not Merge).
I did a quick rebuild (recreation) of a couple of the CFs I had and the output worked as expected on the front-end.
That’s brilliant to know, thanks for checking. I haven’t been able to reliably test recent changes on my live server because I’ve had so many partial pushes to it that it seems to be corrupted. Tags don’t seem to output anything (or nothing gets stored via the back-end: I haven’t debugged which).
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline