Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#136 2011-06-06 14:18:17
Re: The direction of Textpattern 5
Starting from this thread I put on an admin Theme based on Tom Reno mockup linked above, but with actual txp. It is working, as you may see here, with some caveats for some table#list. I haven’t publicly released it because it’s not my design, just a coding exercise. If Tom Reno doen’t mind I could make it public. Or, if someone would like to try it, let me know (I posted here because no one of you two, mrdale and funtoosh, who liked the design answered the other thread). I could privately send you a copy. That would also help development/refinement.
Offline
#137 2011-06-06 16:32:09
Re: The direction of Textpattern 5
What’s the status on TXP5 development at the moment? I’d like to get involved in shaping the future structure of the admin side HTML. I know there was going to be a public repo a la Github but the Mercurial TXP5 repo on Google Code has not had any additions for a few months (not sure if it is even going to be used).
Offline
#138 2011-06-06 21:16:25
Re: The direction of Textpattern 5
+ Content Types (Article, Visual(Image, Video), Links(link type))
Offline
#139 2011-07-04 19:28:41
Re: The direction of Textpattern 5
Escher 0.9.2 (just released) supports integrated branch management to dramatically simplify site maintenance and deployment. I just blogged about the new feature here. Something you’d like to see in TXP 5? Pro or con, please share your comments.
Offline
#140 2011-07-06 07:25:08
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: The direction of Textpattern 5
Hi Sam,
Branch management sounds like an excellent feature. At the moment I’m doing this manually. Each of my websites has 3 versions in 3 different locations – local on my Mac, staging on my hosting & live on the client’s hosting. I then use FTP to transfer the DB, images, CSS etc. The “master” copy is generally local & the system works fine. Gets a bit awkward when the client is updating their own site – I have to then be very careful! Built-in functionality to maintain & synchronise the different branches would be a fine enhancement.
Adi
Offline
#141 2011-07-06 07:49:52
- Algaris
- Member
- From: England
- Registered: 2006-01-27
- Posts: 604
Re: The direction of Textpattern 5
artagesw wrote:
Escher 0.9.2 (just released) supports integrated branch management to dramatically simplify site maintenance and deployment. I just blogged about the new feature here. Something you’d like to see in TXP 5? Pro or con, please share your comments.
I agree this sounds like an excellent idea for TXP5. In my job I’m designing a new website that will be powered by Textpattern which I’ll be responsible for updating and adding new features to. Branch management will allow me to work on these changes, show them to my boss for a approval and push them to the live site without having to export the database and manually replace all the files.
Last edited by Algaris (2011-07-06 11:25:24)
Offline
#142 2011-08-02 19:37:22
Re: The direction of Textpattern 5
cough Custom Content Types.
:)
Offline
#143 2011-08-10 20:53:28
Re: The direction of Textpattern 5
renobird wrote:
cough Custom Content Types.
I also think this needs to be a major focus of Txp 5. Since playing with Django over the past year (something I would highly recommend for the adventurous), I’ve realized there are several things Txp could learn from web frameworks like Django / Rails. Having unlimited custom content types (and a consistent ORM to query them) is one of them. glz_custom_fields with txp:article has allowed us to do a lot of magical things with Txp 4.x, but we are admittedly still limited by the underlying architecture.
We should be able to subclass some base content type(s) and build our own using a selection of custom fields. I imagine making a “song” content type, for instance (with artist, album, length, rating fields, etc…), and query it using a common ORM to the database, a la txp:article / article_custom, but with the tag replaced as txp:song. The txp:song tag would become available based on the name (‘song’) you’ve given your custom content type.
Is this too ambitious or is this already in the works and I’m preaching to the choir?
Textpattern’s greatest strength for me has always been it’s adaptability to build websites with different needs. We always talked about how WP was great for building blogs, but not every site is a blog. I think working on custom content types should be a main priority for the future of Txp to continue this tradition of being not only the most designer friendly, but the most adaptable CMS out there.
Offline
#144 2011-08-10 21:03:16
Re: The direction of Textpattern 5
aswihart +1
Offline
#145 2011-08-10 21:08:12
Re: The direction of Textpattern 5
aswihart — that pretty much sums it up.
Devs — any chance this is being pursued?
Offline
#146 2011-08-10 22:04:38
Re: The direction of Textpattern 5
Please take a look at Escher, specifically pages with custom page parts and custom metadata, and models to capture recurring combinations of page parts/metadata.
In Escher, I can easily imagine setting up a page model for a “song” page type with custom page parts (and/or metadata – you choose) for artist, album, length, rating, etc. Querying for songs would be done via Escher tags, just like any other page. Since songs are modeled as pages, they each have a unique URL, and so are proper RESTful resources as well.
If this type of approach meets your needs, then yes, I would say it is possible. If not, then I can’t say anything more definitive at this point, but Stef, Jeff and Robert may have other ideas.
Offline
#147 2011-08-10 22:17:42
Re: The direction of Textpattern 5
Sam, thanks for all your work on Escher. I love the way you can do just the things people are asking about here. I also like the staging/testing functionality.
However Escher is a major WIP right now. I for one would hate to see potential new directions for TXP watered down because they exist in Escher already. Escher isn’t really an option yet for many of us, as there is a laundry list of required functionality that either represents a lot of work or a lot of waiting.
For example, at this point it would be much easier for me to move all TXP sites to e.g. ProcessWire in search of native custom content types than it would to go from TXP to Escher. ProcessWire already has a few choices of admin theme, quite a few community contributions and a level of polish that really shines in a demo.
However, I’m excited to see Escher grow and look forward to seeing new developments there. I just hope that Escher++ doesn’t imply TXP5—.
Offline
#148 2011-08-10 22:44:18
Re: The direction of Textpattern 5
Sam — Thanks for your response, I apologize I’m not very familiar with Escher, but it sounds like it supports custom content types in the way you described. Surely, there is no reason Txp 5 couldn’t do something similar, with its own conventions, the question is will it happen?
I’d like to give Escher a try sometime, I’ve just briefly poked around the demo admin, looks powerful! But to be honest I’m currently on a Django binge that I don’t see ending any time soon. The learning curve is steep compared to any CMS (save perhaps Drupal?), but now that I’m comfortable with it, I’m addicted to the unparalleled flexibility a web framework provides, not to mention the fact that you can build web apps with it.
Still keeping a keen eye on Txp though and have high hopes for its future!
Offline
#149 2011-08-10 23:22:16
Re: The direction of Textpattern 5
maruchan wrote:
However Escher is a major WIP right now. I for one would hate to see potential new directions for TXP watered down because they exist in Escher already. Escher isn’t really an option yet for many of us, as there is a laundry list of required functionality that either represents a lot of work or a lot of waiting.
I’m not proposing you switch to Escher. Simply that you look at the way it solves some of these problems, because if they are reasonable solutions within the context of Textpattern, then they might be ported to Textpattern more quickly than devising entirely different solutions.
I’d like to hear the items on your laundry list, because that can only help me to improve Escher. For my part, I can’t imagine any kind of site that I could build in Textpattern that I could not also build quite easily in Escher. Lack of themes is a legitimate issue, but one that will be resolved in time as more people begin using it. Still, that’s not related to the software’s core functionality, which is already quite strong.
Offline
#150 2011-08-10 23:44:44
Re: The direction of Textpattern 5
I’m not proposing you switch to Escher. Simply that you look at the way it solves some of these problems, because if they are reasonable solutions within the context of Textpattern, then they might be ported to Textpattern more quickly than devising entirely different solutions.
Ah, that makes a lot of sense to me. Re-reading my post I think I came off a bit critical, apologies for that. But I think I had been reading an “Escher already has…and TXP5 wants to stay true to TXP, so…” stance into some TXP5 discussions and was a bit concerned that my hopes and dreams would not be coming to TXP5. ;-)
I’d like to hear the items on your laundry list, because that can only help me to improve Escher. For my part, I can’t imagine any kind of site that I could build in Textpattern that I could not also build quite easily in Escher. Lack of themes is a legitimate issue, but one that will be resolved in time as more people begin using it. Still, that’s not related to the software’s core functionality, which is already quite strong.
I don’t know if I agree about what is or isn’t core functionality, but I’m really happy to see that you’re actively improving the software.
I mentioned this to you on Twitter but I think that working with assets is a bit rough right now. Drop-down menus for choosing images are fine for a demo site, but I know my clients with 100+ images would want a sortable list + search functionality. Ditto with files.
That is not what you would call core functionality, but to me this is a vital area to cover for even an average user experience. For users who are only using Escher for personal projects, maybe not so much.
Anyway, end of derail…
Offline