Situation report for Textpattern 4.6 and beyond

Destry · 2014-02-15 10:05:22

Bloke wrote #278776:

…I might put some effort into writing a migration plugin for glz_custom_fields (the core will only cater for its own fields: varchar)

Was just coming here to ask about that. I haven’t really relied on glz_CFs before, but I’m currently in a position that needs thinking about it for the simple reason of field types (principally textarea) other than text boxes. I could just sit with using core for now if that would make for lower-overhead upgrade come 4.6. In fact, I’d rather do that if it made for easier upgrade and made your life easier too.

…and finally extend the fields out to images, files and links.

Why not? ;)

Maybe users too, which might remove the necessity for smd_bio.

Makes sense… But then do you bring user_manager functionality too?

For clarification, I doubt all this will be in the first drop. I’d like to get articles done for 4.6.0 and then roll support for the remaining content types out in subsequent releases.

I think anything more would put people into shock. Better take this new dope in stages.

Destry · 2014-02-15 10:08:30

@wet and phil, Thanks.

Destry · 2014-02-24 08:00:39

Praying to the golden vache that forces align on Bloke’s effort with native custom field extension in Articles for 4.6. For me, it’s the single-most anticipated new feature and (along with the Markdown filter) worthy of a 4.6 launch alone. So, yeah, Phil, be sure to take it into account in the UI. ;)

tye · 2014-03-04 22:04:26

Bloke, Other Devs – just a quick question regarding custom fields.

I know in the past you have been awesome in making TXP upgrades backwards compatible with certain plugins and so on. So I was wondering what will happen to sites using Gerhards custom fields when custom fields are brought into the core?

Will they still work standalone as they are? Will they be some merge during the upgrade?

Just asking as I got an upgrade to do on a txp site which is going to use a lot of custom fields.

Thanks

Bloke · 2014-03-04 22:31:12

tye wrote #279447:

what will happen to sites using Gerhards custom fields when custom fields are brought into the core?

Core won’t pander to plugins, regardless of how awesome they are, because that’s a hiding to nowhere. Think about the different versions of glz_cf, for example. Trying to migrate data might well cause core upgrade problems, which we can’t risk.

The best I can offer — subject to this damn thing working at all(!) — will be a glz_cf migration script that pulls custom field definitions > 10 into the new CF table, and imports the data as best as it can into the core tables that hold CF values.

It’ll be up to you to delete the original custom_N fields from the textpattern table, mostly as a fallback in case something during migration goes wrong so you can copy the data out manually without losing anything.

Oh, and regarding whether glz_cf will work on a 4.6 install, the answer is “maybe”. At present I’ve hacked the existing functions during testing, which means they’re most certainly NOT backwards compatible. But if it works, I’ll probably migrate the code to a PSR-0 style structure and revert the existing functions to their current functionality which means glz_cf would continue to work alongside core CFs. Lots of unknowns at present, so nothing is concrete.

Last edited by Bloke (2014-03-04 22:33:42)

philwareham · 2014-03-04 22:37:15

That’s the right approach I think. I’d rather the custom fields were the best implementation they possibly could be, and not hindered by having to support legacy plugin code.

tye · 2014-03-05 02:05:31

Thanks for the transparency – answers a few questions – it was just something I needed to be aware of :)

bici · 2014-03-05 03:25:57

philwareham wrote #279450:

That’s the right approach I think. I’d rather the custom fields were the best implementation they possibly could be, and not hindered by having to support legacy plugin code.

+1

one way is to list what will not be supported. then folks have the choice of not upgrading until they get their stuff in order.

4.6 is a clean break. “don’t upgrade until you have determined what will not be supported. Questions? Contact the plugin author “

Destry · 2014-03-05 08:29:39

Bloke wrote #279448:

subject to this damn thing working at all(!)

Say it ain’t so, Bloke. Say it ain’t so! Get the whole damn squad working on it if you have to.

(And, right. Old plugins should be adapting to core, not the other way around. Time to move forward.)

sacripant · 2014-03-05 10:18:55

Hi! Txp devs,

I am very happy with what I read here.

I have a question concerning the implementation of new custom fields :
Is it possible, as does glz_custom, fill a custom field (a select for example) with results coming from an sql querie (article list, image list, etc.). ?
If yes, what will be expected to write these queries? php (as glz_custom make) or Textpattern tags ?

I use it on multiple sites / projects to create relationships between items.

Second question :
Custom field work is available on a public branch?

Thank you for your work.

jakob · 2014-03-05 10:41:35

Tye, thanks for asking and Stef, thanks for the honest answer. I was also wondering what the state of play was for a large upcoming project. I can see you’ve all been busy pushing things forward for a while, but it sounds like 4.6 ist still a way off, then? Either way, I’m excited to see the way things are going.

philwareham · 2014-03-05 10:44:57

sacripant wrote #279463:

Custom field work is available on a public branch?

Not at present. I’ve not seen it myself yet (and I’ll need to amend the HTML of the admin pages quite a bit to allow it) – Stef is still beavering away on the underpinnings of it at the moment.

Bloke · 2014-03-05 11:22:46

sacripant wrote #279463:

Is it possible, as does glz_custom, fill a custom field (a select for example) with results coming from an sql querie (article list, image list, etc.). ?

Up ‘til now I’ve focused on the public side of things to make sure that it’s possible to get the data out in a reliable fashion when it’s spread across multiple tables. That’s working sweetly, even taking expired fields into account.

I’ve started work on the admin side now, which is, shall we say, ‘fun’ to do efficiently, especially given that:

The UI element partials that were previously static (per article) I would like to become dynamic, when you change section, for example.
The defined fields for the given article need to take the Posted date into account. Old articles might have a different set of fields than newer ones, for example. Though I think I’ve ruled out dynamically changing the fields on change of Posted date because it may cause too much confusion / data loss. Not sure yet.
Data for each field needs populating for existing articles, default values may need populating otherwise.
UI options for select lists and radio/checkbox sets need displaying. The lists themselves will be configured up-front when the field is set up, but there will probably be a callback per field at render time so if you want to dynamically populate the options or alter the field in any way, that’s the place to do it. The caveat of course is that if you change a set of options to include one that doesn’t exist any more, it won’t be selected. I hadn’t thought about using Txp tags to build the results. Allowing the data to be loaded from a Form might be a useful thing to do. This kind of thing does mean it’s up to you to make sure the admin side doesn’t break from a rogue option. Might have to put some safeguards in place, but I’ll see what can be done as this thing progresses.
Saving data needs to be atomic/transaction-based because it’s not just in one table any more.
As Phil says, it’ll need some markup alterations on the Write panel to make it effective. For now, I’ll just bung them all under the Custom Fields twisty until we can figure out a better solution.

Then there’s the screen to be able to actually administer the fields, names, properties, etc. But that’s relatively easy in comparison.

Fun fun fun.

philwareham · 2014-03-05 11:33:16

I’ve got to put the new grid layout into the trunk soon, I’ve got it on my local development build at the moment.

That’ll allow us more flexibility in how fields are arranged on the various columns. Maybe we can work something out using jQuery UI sortable to allow users (with certain permission levels) to re-arrange fields and panels. I need to play around with some structural stuff once I’ve put the new grid in, and see if it’s feasible.

I’m snowboarding next week but it’s on my list of to-do stuff after that. There’s a substantial Hive theme update waiting to be rolled into the CMS too. Plus minor updates to Remora/Classic so they fit our latest design patterns.

I’ve had four months working solid on a Drupal site so I need a weeks break first to regain some sanity.

etc · 2014-03-05 11:53:25

A Titan work is going on here, you guys are bringing back txp early days excitement, huge thanks!

Bloke wrote #278776:

One of the conventions I may adopt is that this ‘group’ refers to a Section for article custom fields, which means that per-section CFs can be constructed if you wish right out of the gate.

IMO, Sections are already overcharged, wouldn’t introducing some Prototype entity be a better choice?

Textpattern CMS

Textpattern CMS support forum

#16 2014-02-15 10:05:22

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #278776:

#17 2014-02-15 10:08:30

Re: Situation report for Textpattern 4.6 and beyond

#18 2014-02-24 08:00:39

Re: Situation report for Textpattern 4.6 and beyond

#19 2014-03-04 22:04:26

Re: Situation report for Textpattern 4.6 and beyond

#20 2014-03-04 22:31:12

Re: Situation report for Textpattern 4.6 and beyond

tye wrote #279447:

#21 2014-03-04 22:37:15

Re: Situation report for Textpattern 4.6 and beyond

#22 2014-03-05 02:05:31

Re: Situation report for Textpattern 4.6 and beyond

#23 2014-03-05 03:25:57

Re: Situation report for Textpattern 4.6 and beyond

philwareham wrote #279450:

#24 2014-03-05 08:29:39

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279448:

#25 2014-03-05 10:18:55

Re: Situation report for Textpattern 4.6 and beyond

#26 2014-03-05 10:41:35

Re: Situation report for Textpattern 4.6 and beyond

#27 2014-03-05 10:44:57

Re: Situation report for Textpattern 4.6 and beyond

sacripant wrote #279463:

#28 2014-03-05 11:22:46

Re: Situation report for Textpattern 4.6 and beyond

sacripant wrote #279463:

#29 2014-03-05 11:33:16

Re: Situation report for Textpattern 4.6 and beyond

#30 2014-03-05 11:53:25

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #278776:

Board footer