The direction of Textpattern 5

michaelkpate · 2011-08-24 12:37:12

aswihart wrote:

Git for Windows works fine.

That quote was from 3 years ago so things may have changed. I tried the windows client once and had trouble figuring it out but I didn’t spend much time with it.

AdamK · 2011-09-29 10:59:18

Hello

I’ve been using TXP for some years/projects, and I’m extremely interested in it’s future, so let me add my five cents ;)

My point of view: designer/web developer (doesn’t know PHP, loves TXP tags) for people outside the TXP/Textile community

1) The branching in Escher is an awesome concept, I would pay to see something like this in TXP.

2) interface similar to cnk_versioning (since installing Aptana Studio & this plugin I have not used the web interface in the current project at all)
2a) (more as a plugin wish) interface for sass / Turbine etc. When we get css from the DB, why not to transform it on the fly (css variables…)? And then save the transformation to the static files for Production branch (see above) a’la rvm_css…

3) include some low-level plugins into the core (aks_header, rah_post_versions, sitemap, rss_admin_db_manager). They have quite long release cycles anyway, and because of their low-level job it is a huge problem when the core changes (see rss_admin_db_manager for example).

4) images… rebuild, please, the images tab: let’s say Picasa-way: category as a thumbnails’ gallery, massive upload, batch thumbnail creation/resizing/re-categorization/rename. Article-side: multiple images per article, adding pictures when creating the article, XML_RCP interface for image uploading for desktop WYSWIG blog publishing. I feel that images-issue is THE most underdeveloped part of the current TXP (and it may be so because of the concept and design of the user-side workflow, which originates in an ancient times of text-oriented content??)

That is quite a description of Textpattern of my dreams ;)

Ha, and one more: Why not to distribute TXP with some plugins imported by default? For example I’d move the comments feature out to a plugin. Then one could choose, either he/she wants to use the TXP comments solution or s/he’d rather plug-in an external commenting solution, Disqus for example.

Yours
Adam

P.S. I second the discussion of removing/opening the categories of forms. The default names are confusing and misleading, suggesting that there is any difference between misc, article and links forms, where there is none.

Last edited by AdamK (2011-09-29 12:26:41)

philwareham · 2011-09-29 11:15:29

@Adam

Totally agree with that.
Personally I think having both options (the standard way, the cnk_versioning way) is best, having tried cnk_versioning myself I actually still prefer the standard way of updating forms/pages/styles. With regard to Sass, I’m a massive fan (in fact I’m using it in the TXP5 admin-side redesign), but I’d not want any preprocessing done server-side.
Again, I agree that some plugins really could be part of the TXP5 core, but the devs would have to be extremely selective about which ones would benefit (and not make the core harder to upkeep).
Image management is something that will be investigated in the admin-side redesign – when I’ve got the admin template mockups a bit more finalised I’ll let the community start looking over them and suggesting how that area can be displayed best. I’ve not looked at the images section at all yet.

merz1 · 2011-09-29 14:40:47

From a marketing and a product point of view I support the argument that TXP needs some database management tools in core. Doing a daily backup and/or before/after publishing can’t be so hard to achieve but is a valuable safety argument when choosing a CMS.

Some time ago I supported the idea that the core dev team should adopt some plug-ins to assure compatibility with newer TXP versions.

Last edited by merz1 (2011-09-29 14:41:05)

ruud · 2011-09-29 17:35:55

Doing automated backups is not done through a plugin, but by running a CRON job that uses mysqldump and then transfers the dumpfile automatically to an off-site location. Not difficult, really.

mrdale · 2011-09-29 17:51:03

automysqlbackup

I agree backups are best handled separately.

merz1 · 2011-09-29 20:48:49

You are both right but why not integrate such a ‘backup for designers’ feature? (I know PHP can also do a lot of things but we insist in using XHTML like tags)

No, please, I don’t want to start that discussion.

Last edited by merz1 (2011-09-29 20:50:59)

alanfluff · 2011-10-02 17:08:44

Summary

This is a bit of a prosaic suggestion/request and not at all to do with the ‘direction’ of TXP 5, sorry if this should not be here. I would greatly value an Admin feature that did this:

In the Amin panel, the website designer is able to be globally enable/disable a feature that when enabled would cause TXP to consider the source for TXP Pages and Forms to be flat files in a specified folder rather than what was store in the db.

During dev this would allow Pages and Forms to be edited in a text editor without copy/pasting for results to be seen.

Background

I don’t know if I am alone in doing it, but I maintain all Pages and Forms as text files for each site. E.g.:

/mysite/_mySpecialFolder/page_archive.php
/mysite/_mySpecialFolder/page_404.php
/mysite/_mySpecialFolder/form_default.php
/mysite/_mySpecialFolder/form_anotherFormIwrote.php

Currently, each time I develop the site I edit the code in these files (with the benefits of the code editor I choose) and copy/paste the changed Pages or Forms to TXP and save and refresh.

With the feature I am suggesting I envisage that in the Admin i/f there would be a tick-able option: ‘Use flat files for Pages/Forms’.

If ticked, the admin i/f would either look in set location expecting a set naming convention to look for files, or, it would allow me to enter the path where it should monitor (allowing for varied file naming conventions sounds like it’s not worth doing).

So in my case, I would tick the option and enable it and enter the folder name ‘_mySpecialFolder’.

With that done TXP would look in that folder for any files that were legally named, matched an existing Page or Form and if a match was found it would use the contents of the file rather than the code held in the db for that matched Page or Form.

Safeguards

Perhaps the facility should be only enable-able if TXP was in debug mode (so it could not be left on by accident when a site was going to Production).

Conclusion

I have been mulling this over for a long time. I have worn out a few keys with the amount of Ctrl C Ctrl V I have done over time updating the code in Pages and Forms.

It seems to me this would be a genuine benefit to the person developing a site.

I hope this suggestion has been helpful.

Cheers, -Alan

maniqui · 2011-10-02 17:27:51

Alan, I think that, till now, you never heard of cnk_versioning. Enjoy!

Algaris · 2011-10-03 07:21:00

I use cnk versioning for every project I work on and couldn’t imagine using Textpattern without it now.

alanfluff · 2011-10-03 10:37:27

Julián (and Ross); THANKS! :D dancing

Algaris · 2011-10-03 10:43:39

Just don’t forget to make the mod mentioned in the plugins thread in order for it to work with the latest version of Textpattern.

Textpattern CMS

Textpattern CMS support forum

#229 2011-08-24 12:37:12

Re: The direction of Textpattern 5

#230 2011-09-29 10:59:18

Re: The direction of Textpattern 5

#231 2011-09-29 11:15:29

Re: The direction of Textpattern 5

#232 2011-09-29 14:40:47

Re: The direction of Textpattern 5

#233 2011-09-29 17:35:55

Re: The direction of Textpattern 5

#234 2011-09-29 17:51:03

Re: The direction of Textpattern 5

#235 2011-09-29 20:48:49

Re: The direction of Textpattern 5

#236 2011-10-02 17:08:44

Re: The direction of Textpattern 5

Summary

Background

Safeguards

Conclusion

#237 2011-10-02 17:27:51

Re: The direction of Textpattern 5

#238 2011-10-03 07:21:00

Re: The direction of Textpattern 5

#239 2011-10-03 10:37:27

Re: The direction of Textpattern 5

#240 2011-10-03 10:43:39

Re: The direction of Textpattern 5

Board footer