Textpattern's ongoing development

gaekwad · 2026-01-11 22:17:22

Bloke wrote #342175:

Makes sense. I was thinking each rev would get its own branch and we’d delete the old one but, for continuity sake and less faff with scripts, you’re right that it makes sense to use a generic name.

Prior to today, we used dev and published a tag for each release, so a similar workflow would work just fine: use 4.9.x in place of dev for the v4.9 releases, and tweak the toolbelt script so it uses the correct branch.

My gut feeling is that we need to spec this split out a bit more before we commit to it as it has knock-on effects with the other repos as well as downstream cloners. Would you be open to a bit more discussion, Bloke?

gaekwad · 2026-01-11 22:22:48

Bloke wrote #342175:

Anyone fancy taking a stab at renaming a branch can do so from GitHub, but that has ramifications for people whom have cloned already when syncing, as outlined in the link above.

~~According to this the 4.9.1 branch is 425 commits behind dev, which seems high…does that make sense to you, Bloke?~~

Edit: actually, it looks like the custom-fields stuff folded in accounts the commits. Ignore the above

Last edited by gaekwad (2026-01-11 22:26:41)

Bloke · 2026-01-11 23:58:33

gaekwad wrote #342177:

Would you be open to a bit more discussion, Bloke?

Always.

philwareham · 2026-01-12 08:15:34

Hi. I have now created 4.9.x branches on the Textpacks and themes – as requested. Cheers!

gaekwad · 2026-01-12 14:53:54

Bloke wrote #342175:

Anyone fancy taking a stab at renaming a branch can do so from GitHub, but that has ramifications for people whom have cloned already when syncing, as outlined in the link above.

Given the short-ish timeframe since 4.9.1 was created, and the 4.9.x namespace for branches, it makes sense to change 4.9.1 -> 4.9.x in textpatttern/textpattern sooner rather than later.

I’ll take dibs on this today unless anyone has any objections – paging Bloke and etc for any blockers on technical / moral / idealistic grounds.

Bloke · 2026-01-12 15:22:30

Nah, it’s good. Just rename it.

If you do it, let me know. If not I’ll be able to get to it in half hour or so.

gaekwad · 2026-01-12 15:23:26

Bloke wrote #342193:

Nah, it’s good. Just rename it.

If you do it, let me know.

Dibs. Please stand by.

gaekwad · 2026-01-12 15:26:46

Bloke wrote #342193:

Nah, it’s good. Just rename it.

Done: github.com/textpattern/textpattern/tree/4.9.x

Bloke · 2026-01-12 15:41:54

Fab. Thank you.

Bloke · 2026-01-13 00:30:33

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.

jakob · 2026-01-13 22:22:48

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?

Bloke · 2026-01-13 22:58:28

jakob wrote #342218:

partly due to year number changes, I guess.

Mostly that!

Am I right in assuming that the dev branch 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.

phiw13 · 2026-01-14 00:34:53

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.

jakob · 2026-01-14 08:39:19

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.

jakob · 2026-01-14 08:44:29

jakob wrote #342218:

Am I right in assuming that the dev branch 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.

Textpattern CMS support forum

#16 2026-01-11 22:17:22

Re: Textpattern's ongoing development

Bloke wrote #342175:

#17 2026-01-11 22:22:48

Re: Textpattern's ongoing development

Bloke wrote #342175:

#18 2026-01-11 23:58:33

Re: Textpattern's ongoing development

gaekwad wrote #342177:

#19 2026-01-12 08:15:34

Re: Textpattern's ongoing development

#20 2026-01-12 14:53:54

Re: Textpattern's ongoing development

Bloke wrote #342175:

#21 2026-01-12 15:22:30

Re: Textpattern's ongoing development

#22 2026-01-12 15:23:26

Re: Textpattern's ongoing development

Bloke wrote #342193:

#23 2026-01-12 15:26:46

Re: Textpattern's ongoing development

Bloke wrote #342193:

#24 2026-01-12 15:41:54

Re: Textpattern's ongoing development

#25 2026-01-13 00:30:33

Re: Textpattern's ongoing development

philwareham wrote #342181:

#26 2026-01-13 22:22:48

Re: Textpattern's ongoing development

#27 2026-01-13 22:58:28

Re: Textpattern's ongoing development

jakob wrote #342218:

#28 2026-01-14 00:34:53

Re: Textpattern's ongoing development

#29 2026-01-14 08:39:19

Re: Textpattern's ongoing development

phiw13 wrote #342220:

#30 2026-01-14 08:44:29

Re: Textpattern's ongoing development

jakob wrote #342218:

Bloke wrote #342219:

Board footer