The direction of Textpattern 5

thebombsite · 2011-01-21 22:27:39

Bloke wrote:

The default install should contain one or two groups to house the scant few default forms that we actually need, and you should be able to add / rename as many groups as you see fit to suit your site.

That would be awesome. I could split that “always miles too long” Miscellaneous block into smaller, meaningful blocks.

hcgtv · 2011-01-21 23:22:04

thebombsite wrote:

That would be awesome. I could split that “always miles too long” Miscellaneous block into smaller, meaningful blocks.

Here you go, a how-to for adding more form types.

gomedia · 2011-01-22 00:41:42

“One click” TXP software upgrade would be great.

Built-in database backup & restore too.

gomedia · 2011-01-22 00:49:48

and, please, no more:

Add article
List articles to get new ID
Memorise ID
Go to another tab
Forget ID
Go back to article list
Memorise ID again
Go to that other tab somewhere
Type in ID

Drag & drop? Multiple admin panes – Articles on one side, Forms on the other?

maniqui · 2011-01-22 03:45:05

ruud wrote:

Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.

hcgtv wrote:

Personally, I like the distinction of Page and Form.

Lot of things could change in TXP5 paradigm, making current concepts/workflow to become obsolete.

I like ruud’s suggestion on “merging” both Pages and Forms under the same tab (personally, I don’t use those tabs any more, cnk_versioning has been my ally since long ago), although I would keep some kind of categorization.
Currently, in TXP4, categorizing a chunk of code as “page” serves, at least, one purpose: to be able to select that chunk of code as the rendering template for a particular section. In other words: a section must be assigned-to/matched-with a page template (that’s the built-in way, which currently can be bypassed with a plugin like gbp_permanent_links).

Combining “forms” and “pages” without keeping some categorization could break this section-to-page-template paradigm, and users could make the mistake of trying to do section-to-any-chunk-of-txp-code, which, in current TXP4 paradigm won’t work (unless the “form” contains the full code for a template).

hcgtv wrote:

I would eliminate Form Types though, they serve no purpose other than to confuse at first.

It confuses because newcomers believe that categorizing a form would make it work differently depending of the selected type. If it could be stated in a little tooltip that the type of a form doesn’t interfere with its functionality, that would be enough to avoid the confusion.
That being said, I like categorization of forms, and I’d suggest to keep it, and even letting the user (or a plugin) to create their own categories.
Bert, I saw your post on how to add form types.
I posted some ideas about new form types in the past.
I think new form types could play nice with plugins that would let end-user freely edit them, without having access to forms & templates.
For example, a “microcopy” form type, for managing short text & copy (widget headings, footer text, meta data, etc) that wouldn’t fit the “article” model. A current way to manage “microcopy” in TXP4 is possible using adi_variables.

Other topic:

Devs already mentioned that, in TXP5, there may be more flexible/custom URL schemes.
Not sure what they have in mind regarding this, but I would suggest them to look at:

gbp_permanent_links, the current “standard” for custom URL schemes in TXP.
Django’s MTV (Model-Template-View, Django’s own interpretation of MVC), and its urls.py way of matching an URL to a “view”.

gbp_p_l provides an UI to create custom URL schemes, and saves them in database. This makes it a bit cumbersome when having to move from development environment to production environment. If there could be a plain-text file with a super-cool syntax to define URL schemes… that would be awesome.

That’s all. By now :)

Gocom · 2011-01-22 04:31:52

gomedia wrote:

Drag & drop? Multiple admin panes – Articles on one side, Forms on the other?

That could work. Actually, the navigation tabs could respond to dragging, so that items could be freely dragged from one pane to other, like you could do in Finder (or Explorer on Windows).

DnD images, links, code blocks. Would be pretty awesome. Oh, and if plugins could freely extend what the even does, and spits out. Could actually make the forms/pages web interface usable, w/o the need of an external editor. But thing is, how many are used to DnD interfaces, and how many would even use it. I know I would, but what about the rest.

Just like Julián, I neither use the form/pages interface at all. Because it handles code, the design should be similiar to an editor. Not a tiny little field at the middle of the page. And the tag builder… the idea behind it is good, but the execution is bad.

Dragondz · 2011-01-23 08:53:44

Hi

Happy to see that some huge change are coming, i am happy with txp now but something dont evolve will die!

If I can add my 2 cents about features to add: a better authorisation process ( ability to restrict user to some sections or categories or something like this).

I tried to see the framework but havent found any documentation about it and how it works!

hcgtv · 2011-01-23 13:18:39

maniqui wrote:

Lot of things could change in TXP5 paradigm, making current concepts/workflow to become obsolete.

Over the years we’ve seen web developers defect to other systems, most notably Expression Engine. So if this paradigm shift is being done to stop loyal web developers from defecting, then just go the EE route and start charging for Textpattern 5.

Nothing in the last 5 years has been done to garner more users, whether it be in making the code base easier for the newbie or in promoting this niche of a system. So obviously the focus is not on someone who just wants to put up a blog or a simple site, it’s more towards the web developer who uses Textpattern as one of the many tools in his or her arsenal. But from what we’ve seen in the past, this does not bring in much money, now does it?

2011 is a perfect year to go after more users, by 2012, they’ll be so much noise in the atmosphere that any project announcements will be drowned out. Now’s the perfect time to strike, newbie tweaks to the core coupled with guerrilla marketing, and we can see a large influx of users. Then get them excited about the new roadmap to TXP5, which will keep the momentum going.

No matter how much you love to code, there comes a time where you want to see the fruits of your labor be rewarded, whether it be from recognition (more users), or from money flowing in from services or donations. So if you like to code in relative anonymity, then by all means, keep the status quo.

thebombsite · 2011-01-23 18:02:31

Plus, considering how many web developers/designers use this application for free, it’s surprising how few emails a get asking if I would put someone’s new theme up on Textgarden, whether it’s free or not. I could probably count them, for a year, on both hands.

mrdale · 2011-01-25 15:36:21

All worthy ideas/discussions and reason for a lot of optimism for the futrue of txp.

Let’s just hope that the ratio of spectators (includes self):devs is high enough to make all this a reality.

artagesw wrote:

Escher has all of the above (well, not nested content types). Read into that what you may.

to tell you the GH truth, I’m a creature of habit and momentum, and I could never quite grok the Escher paradigm, which is more of a statement about me than about your excellent work. I am holding out hope that TXP 5’s differentiation from 4.x will be functionally dramatic but conceptually very similar.

Last edited by mrdale (2011-01-25 15:36:43)

vurt · 2011-01-27 14:10:44

A brief and surely incomplete wishlist:

- integrated database management, ala rss_admin_db_manager

- better search parsing, to include sections, pages, etc.

- version control, ala rah_post_versions

- front side theming, ala WP (frankly I think this is what made WP what it is today.)

- multiple image support for articles (and it needs to be more intuitive for clients. I couldn’t live without hak_article_image, but you have to know how to use it.)

- better storage structure for images (I’m scared of that one giant folder. Should I be?)

- WWCD (What would a client do?)

And, congrats to the dev team for their ambition and ongoing commitment to txp.

jsoo · 2011-01-27 14:56:15

vurt, thanks for the list. All good items.

vurt wrote:

- integrated database management, ala rss_admin_db_manager

I don’t see this as a core function. For one thing, I expect Txp5 to allow databases other than MySQL. To do this well, even for one DB type, is a big job, and I think well beyond the scope of what core Txp should do.

- better search parsing, to include sections, pages, etc.

a la smd_where_used? I agree.

- version control, ala rah_post_versions

See my remarks on DB management.

- front side theming, ala WP (frankly I think this is what made WP what it is today.)

Lots of ways to read the parenthetical comment :)
But yes, this is a must-have.

- multiple image support for articles (and it needs to be more intuitive for clients. I couldn’t live without hak_article_image, but you have to know how to use it.)

I like the idea. I can see different ways to implement this. One would be as now, allow a comma-separated list of images, but then modify article_image to go through the list if you call it multiple times. That is, the first article_image tag gets the first image in the list, the next article_image tag gets the second image, etc. You can do this now with images and offset, but that’s cumbersome.

Another idea is to allow article_image to call custom fields by name, so that you can create custom fields for specific image roles within articles. Of course, you could do that now with image by setting id to the custom_field value, but that’s cumbersome.

- better storage structure for images (I’m scared of that one giant folder. Should I be?)

At the least, there is strong support for separating content images from design images. But clearly, there’s a lot that could be done in this area.

- WWCD (What would a client do?)

Making the admin more customizable and user-friendly are important goals.

Bloke · 2011-01-27 15:24:00

jsoo wrote:

the first article_image tag gets the first image in the list, the next article_image tag gets the second image, etc.

Interesting. Not considered that approach before.

Regarding images, I still maintain that the core should support the lowest common denominator on the admin side and let plugins twist the interface to fit the ever-changing needs of clients. For example, unless it is done incredibly well, I would not like to entertain the notion of having an image picker directly on the Write tab (a link to a popup, stripped down version of the Images tab would, however, be rather handy).

If the core did it as a select list of filenames, someone would want thumbnails. If we did it as thumbnails, someone else would complain it takes up too much space. And someone else would complain that it needed to show the full size image on hover (others might want this onclick). The sheer number of configurations is overwhelming and to implement one of them as core means alienating a whole bunch of people.

The current configuration of allowing a simple list of IDs to be entered is the absolute minimum that TXP can do. It’s not ideal, but there are plugins out there that allow you to visually pick images. To my knowledge, since the introduction of TXP 4.3.0, not one plugin (umm, well perhaps redbot’s: I’ve never used it) has capitalised on the ability to completely replace the Article image field with a hidden field + a flexible uploader. jmd_img_selector was the closest I saw (ages ago).

So, while image management on the Write tab might seem attractive in core, it would need very careful consideration. I’d rather spend time making the admin side more configurable to allow plugins to easily offer this ability than to put a stick in the ground and force everyone to use something that only fits a handful of image-heavy users. Not saying it’ll never happen, but if it happens, it probably won’t be me who codes it :-)

vurt · 2011-01-27 15:54:42

For example, unless it is done incredibly well, I would not like to entertain the notion of having an image picker directly on the Write tab (a link to a popup, stripped down version of the Images tab would, however, be rather handy).

Is there a reason why you can’t have a picker that navigates to your image bank, so that you can select it from there and upload it, rather than having to memorize the image id in a separate tab? (I’m speaking strictly from a client’s viewpoint.)

This also gets back to:

front side theming, ala WP

Both of these things speak to what makes a CMS competitive with other CMSs. Front end developers need a product that they can “sell” to a client. I’ve had more that one client insist on wysiwyg for writing articles, and the image tab blows their minds (apparently for some this isn’t too difficult.)

That being said, I don’t have a problem with how it works, but some clients do.

mrdale · 2011-01-27 16:20:56

Bloke wrote:

Article image field with a hidden field + a flexible uploader. jmd_img_selector was the closest I saw (ages ago).

This is a no-brainier to be included in core. When I do demos, I show this method of association first and then show customers what it does behind the scenes. They just get it.

I agree with keeping core image control simple. In fact I think the current setup (excluding the UI implementation which is clunky) is about as straightforward as it can get. I’d just like to see a more visual image tab. One that follows a simple grid of images is far more space efficient and immediate.

Image caching, multiple image sizing, and all kinds of sexiness should be handled by tags & plugins. IMHO

Last edited by mrdale (2011-01-27 16:21:11)

Textpattern CMS

Textpattern CMS support forum

#31 2011-01-21 22:27:39

Re: The direction of Textpattern 5

#32 2011-01-21 23:22:04

Re: The direction of Textpattern 5

#33 2011-01-22 00:41:42

Re: The direction of Textpattern 5

#34 2011-01-22 00:49:48

Re: The direction of Textpattern 5

#35 2011-01-22 03:45:05

Re: The direction of Textpattern 5

#36 2011-01-22 04:31:52

Re: The direction of Textpattern 5

#37 2011-01-23 08:53:44

Re: The direction of Textpattern 5

#38 2011-01-23 13:18:39

Re: The direction of Textpattern 5

#39 2011-01-23 18:02:31

Re: The direction of Textpattern 5

#40 2011-01-25 15:36:21

Re: The direction of Textpattern 5

#41 2011-01-27 14:10:44

Re: The direction of Textpattern 5

#42 2011-01-27 14:56:15

Re: The direction of Textpattern 5

#43 2011-01-27 15:24:00

Re: The direction of Textpattern 5

#44 2011-01-27 15:54:42

Re: The direction of Textpattern 5

#45 2011-01-27 16:20:56

Re: The direction of Textpattern 5

Board footer