Let's decide what's actually going into 4.6

gaekwad · 2015-07-06 17:11:43

There’s been a lot of talk and action on Textpattern over the last month or so. As the 1-year anniversary of 4.5.7 approaches, I think it’s about time we figured out exactly what needs to be done before 4.6.0 drops. Working on the semantic versioning approach of major.minor.patch, version 4.6.0 will include minor changes/improvements, plus patches. I am aware ‘minor’ is a weasel word which could encompass all sorts of changes, but bear with me.

I know there isn’t a 4.6 drop date planned. And that’s OK. I also know that there’s a whole bunch of things that would be great to squeeze in before the 4.6 drop date happens. My concern is that feature creep will delay things because everything is considered important, etc.

With that in mind, I’ll put my project manager hat on and ask these questions:

Textpattern developers: what is currently on your roadmap for 4.6.0, please? High level is fine, bullet points are appreciated.
Is the Github 4.6 milestone fully or mostly accurate?
Everyone else: what, in your mind, needs to be in 4.6.0, please?

I’ve already taken on the task of improving Textpattern language translations here and I’m looking for contributions from anyone who can help.

I want this to be done for 4.6, but I know it doesn’t need to be done by 4.6 – this thread is here to figure out what the deliverables are, and from there decide on who can do what – including people outside the small group of developers.

Ladies and gentlemen, let’s talk. What do you need in 4.6?

candyman · 2015-07-06 17:28:43

According to me is better to leave the original roadmap untouched.
So for 4.6 are enough the patches (41 issues to close) and the new admin theme with all jquery effects.

The new template effect could arrive with 4.7.

Maybe the unlimited custom fields and the image selector could deserve the 5.0 number.

Last edited by candyman (2015-07-06 17:32:28)

Bloke · 2015-07-06 17:31:52

My list, for better or worse. It sounds a lot, but I’m infinitely more motivated now than I was a couple of months ago so a lot of it’s quite achievable in very short order, with a little help from my friends.

Yes, that means everyone here, in whatever capacity. Translation, documentation, coding, testing, evangelism…

maverick · 2015-07-06 19:51:56

My feedback, which is worth exactly what you have to pay for it :P

I’m thinking along the lines of Candyman.

Themes, baked in multilingual support, and unlimited custom fields are all excellent improvements. I’m looking forward to them – it’s been a long wait. That said, I’d bump them out of 4.6 to 4.7 through 5.0. Then release more frequently/aggressively on those milestones.

Example:

4.6 – The patches, improved admin, etc.
4.7 – Image Grid
4.8 – Basic Theme Underpinnings
4.9 – Skip? Patches and minor, easy improvements

Since unlimited custom fields, and even themes and multilingual support seem pretty major, they seem to merit a 5.0 designation. Also, because a new multilingual plugin quite likely would need core support plus use of the new custom fields, it may make sense to roll core support and ucf out at the same time.

5.0 – Full Unlimited Custom Fields
5.1 – Multilingual Support
5.2 – Expanded Themes/Templates/Packages
5.3 – Improved User Management (just throwing that one in the mix out of hope :) )

Last edited by maverick (2015-07-06 19:52:59)

Bloke · 2015-07-06 21:51:13

maverick wrote #292682:

Since unlimited custom fields, and even themes and multilingual support seem pretty major, they seem to merit a 5.0 designation.

Maybe. But delaying things like multi-lingual support leaves people using MLP no upgrade path at all until it hits core. Having an International language / Textpack drive now, then leaving multi-lingual sites out in the cold with no way to benefit from the other enhancements seems a little harsh. Maybe MLP can be hacked again to work with it, but the changes in the core make the hack so much harder to accomplish without significant effort. That effort is almost equivalent to just rolling multi-lingual capability into core itself or at very least putting a framework in place so a plugin can offer it. Hack an old hack, or pave a better path: I know which I’d rather work on!

Custom fields can rumble along at whatever pace we set. It has a new branch and as long as I keep it tracking master, they can run in parallel, though the sooner things are merged the better as it’s potentially less work. This is especially true since it’ll be quite a chore to merge in the admin-layout-update to both custom-fields and themes branches — all the library mods and search functionality needs to be merged in to the new panels; mostly by hand as I suspect git will throw its toys out.

CFs don’t have to be present across all content types from 4.6.0. We have them now, we merely continue that notion in 4.6.0, it’s just that they can do more than they can now. Despite the amount of dithering that’s gone on behind the scenes as I figured out the best way to do it, from an end user perspective it’s largely business as usual. You define fields that are assigned to your articles, then store information against them. The underlying technology of how it’s managed is (hopefully) of little consequence.

Same with Themes. I started it this evening. I can probably have it done by the end of the week. It’s one extra admin panel and a new dropdown on each panel in the Presentation area if you add more than one theme to the admin side. If you don’t, you’ll notice virtually no difference: the dropdowns won’t even appear. Is that a major point release? Difficult to say, but major revision changes usually contain paradigm shifts or serious backwards-compatibility-breaking changes. Custom field improvements and basic theme support are neither of those to the end user.

That’s just my perspective of course. It’s no more or less valid than yours!

Bottom line is we need to release something and we need to make sure the core is in good shape for the future, so if that means focusing on bugs and object-oriented code changes, delaying the new goodies a few months, so be it.

Improved User Management

*gasp* You mean smd_user_manager doesn’t do what you want?! :-p

maverick · 2015-07-07 02:33:09

Bloke wrote #292690:

Maybe. But delaying things like multi-lingual support leaves people using MLP no upgrade path at all until it hits core. Having an International language / Textpack drive now, then leaving multi-lingual sites out in the cold with no way to benefit from the other enhancements seems a little harsh.

I thought about that. With the several new websites I’ve been recruited to help with, multilingual capability is in the works for most of of them. In suggesting that it be bumped to a 5.0 release, I would not be immune to the consequence of that decision.

My suggestion was based on several underlying thoughts:

1. Semantic versioning – even if you have to skip from 4.5.x to 5.0, it seems like ucfs and/or multilingual support out of the box are more significant than minor improvement meriting a 4.x.x version number. Likewise with the move to an OO progamming model.

2. While I’m not a fan of buggy releases, or frequent (involved) upgrades, the release early, release often approach tends to generate more of a sense of moment/buzz.

Take the image grid for example. It’s seems like it would qualify for a 4.x upgrade. From what you described it would be a comparatively fast and easy improvement by using code from the existing plugin. So if it were release 4.7 that comes 2-4 weeks after 4.6, that’s awesome. Likewise with basic templates. It almost feels like a major feature addition (5.0) – especially if it is included with ucfs and all the other improvements. By itself though, in a basic implementation, that could be part of 4.7 in a few weeks. Quick turn around with a sense of movement and momentum for the user base, while on the development side things are moving along at the same pace as originally planned.

3. I presumed that baking multilingual predisposition into the core still presupposes a plug is required. To that end, I am also thinking that the plugin may need/want the ucf as well. So even if 4.6 has the m-l fix, they will still have to wait to upgrade. Therefore, as important as MLP is, and as much as it is painful in the short term to leave them stuck at 4.5.7, my thought was to not let MLP drive the roadmap. My example presupposed the intentional, and temporary “leaving” MLP installs stuck at 4.5.x for right now, but with the thought that there might never be a 4.8 or 4.9, and in (just examples I know you should never promise a timeline) 8 -12 weeks there is a shiny new Textpattern 5.0 with ufc and m-l capabilities, and two or more shiny new plugins available to exploit those capabilities.

Obviously I speak only for myself, but it would be worth the slight extra wait and being left frozen at 4.5.x as long as I knew those were the next two things in the road map after the comparatively lower hanging fruit of basic templates and image grid.

Custom fields can rumble along at whatever pace we set.

Do you envision the M-L capabilities, and/or new plugin building on CFs?

CFs don’t have to be present across all content types from 4.6.0.

Either way is fine. Personal preference as an end user would be for the full CF capability at once. That way once CFs are here, I can design the new site with the full power available, not just the articles.

Is that a major point release? Difficult to say, but major revision changes usually contain paradigm shifts or serious backwards-compatibility-breaking changes. Custom field improvements and basic theme support are neither of those to the end user.

That makes sense. Though either can and will likely significantly alter how we work and design with Textpattern.

That’s just my perspective of course. It’s no more or less valid than yours!

Since you are one of the people doing who has invested heavily in the development of Textpattern, I view your perspective as much more valid than mine!

gasp You mean smd_user_manager doesn’t do what you want?! :-p

:P

Seriously though – I rarely do an install without smd_user. But you can only do so much with a plug in when the core wasn’t really designed with it in mind.

With the advent of ucfs, it would seem to me that how plugins approach things like user management, or multilingual functionality, or front side events like form submission, or even comments etc. can/should/will be forever altered and improved.

The best experiences will be ucf + a core that is designed with these types of major plugin extensions in mind + some spiffy new plugins. Which is what it sounds like is the plan you have.

philwareham · 2015-07-07 08:24:19

My worklist of essential things I still need to finish for 4.6 are (again, in no particular order):

Admin layout update (part 1) – Hive, Classic and Remora themes (this is a BIG job).
Grid view option for images.
Single column public side theme.
Improved preferences section.
Finalise ARIA and accessibility support.
Bullet-proof RTL language support.
Version 1 of the design patterns documentation for admin side widgets (Hive and Classic documents – Remora is just a subset of Classic really).

My list of things that would be nice for 4.6 but could be pushed back to a future release:

Admin layout update (part 2) – in truth this will be an ongoing constant piece of work. The UI always needs to be improved.
User definable fields (move fields about, show/hide parts of UI) in write page, image edit page.
Mini list-view of images on Write page for easier insertion of images into articles. Possibly something similar for inserting files too.
Better control of which columns you want to see in list views (i.e., remove the simple ‘more detail’ toggle and actually allow each column to be shown/hidden within reasons – obviously some columns need to be permanently shown.

Things that could definitely wait for a future release:

Inline offline help (Pophelp and Textpacks as part of the install, not reliant on RPC server).
Select from a handful of readymade themes at install time, or start with a totally blank slate.

Outside of the core, I also have:

New documentation website
New Textpattern.com website
To find a solution to a themes/plugins site or resource.

Phew!

philwareham · 2015-07-07 08:28:06

It would be handy if someone could take charge of writing the docblock comments in the core – those have helped me massively in understanding how Textpattern has been put together. It’s only half-done right now though.

hcgtv · 2015-07-07 13:07:52

philwareham wrote #292714:

Admin layout update (part 1) – Hive, Classic and Remora themes (this is a BIG job).

Admin layout update (part 2) – in truth this will be an ongoing constant piece of work. The UI always needs to be improved.

Maybe it’s time to stop shipping the Classic and Remora themes as part of the package?

This is coming from a person that’s used the Classic admin theme from the start, but if it speeds up admin side innovation to just let you concentrate on Hive, then I’ll forego having Classic as an available option.

Ever since upgrading my sites from 4.4.1 to 4.5.7, I’ve been using Hive exclusively, because it feels like it takes advantage of the underlying backend code, where Classic feels more like a skin.

There’s no reason that when the admin side stabilizes, a few revisions down the line, that Classic and Remora, along with any other admin themes couldn’t be brought up to current standards and offered as a download.

It would be handy if someone could take charge of writing the docblock comments in the core – those have helped me massively in understanding how Textpattern has been put together. It’s only half-done right now though.

Point us to some how-to – this is what we’re doing, the steps we’re taking, anybody want to join in?

jstubbs · 2015-07-07 13:38:31

I agree with Bert, why do we need 3 backend themes. Whether one prefers Classic over Remora or Hive is not the issue, in the not too distant future we should be able to create new backend themes.

Save on the workload and ditch the non-essential themes. I do like Classic, but if Hive does the job better then that’s the way to go.

Bloke · 2015-07-07 13:38:51

hcgtv wrote #292742:

Point us to some how-to

Last time I tried, the official PHPDoc spec was a bit annoying to navigate and the examples are pants, but it’s a handy reference if nothing else and they’ve given it a facelift recently.

The best way to figure it out is probably to look at what’s gone in core already, find some functions or files that don’t have the docblocks and add them in the same mould.

Functions, viz:

/**
 * One-line description of what it does.
 *
 * More detailed description can go here, on multiple lines if
 * necessary, normally constrained to about 80 character line
 * length, for readability.
 *
 * These are entirely optional, but are useful to explain any caveats
 * or design decisions in the function that are not immediately
 * apparent. One blank line separates each paragraph.
 *
 * Next come the function parameters. Notice how the blocks
 * line up vertically, using spaces. Also note how the asterisks
 * at the start of each row in the block are indented one space,
 * aligning with the first star of the slash-star-star above.
 *
 * @param  [bool|array|string|...] $variable_name Short description
 * @param  [bool|array|string|...] $another_var   Another description here
 * @return [bool|array|string|...]
 */

function blahBlah($variable_name, $another_var)
{
   ....
}

That’s pretty much it. You can use the same structure to document classes. Variable definitions (class vars: you’ll find these at the top of most classes in the /vendors directory) are a similar format, but much simpler. Again, look at existing variables for examples. We also use:

“@package” to group functions into logical sets when the documentation is built.
“@deprecated” in vx.y.z.
“@see” to reference other functions or to point to replacement functions when deprecating.

I don’t much care for the blank line after the docblock and before the function name because it kind of disassociates the two in my mind, but for some reason Jukka started it like that and I bowed to his superior knowledge of all things code.

btw, if you’re using Sublime Text, get the DocBlockr plugin. If you place your cursor on the row above an undocumented function, hit slash-star-star-enter, it parses the function and creates a docblock automatically based on the function signature it finds. You fill in the blanks. It also keeps alignment nicely for you. Terrific.

Bloke · 2015-07-07 13:40:02

jstubbs wrote #292749:

in the not too distant future we should be able to create new backend themes.

You can do that now :-)

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-06 17:11:43