The direction of Textpattern 5

Bloke · 2012-01-10 10:53:29

philwareham wrote:

If we continue down the 4.x route and use Github I can very easily start improving the admin-side in my own fork, committing patches for approval at various milestones to the core.

Noted, thanks.

artagesw · 2012-01-10 18:26:33

Please don’t confuse GitHub the service with Mercurial the SCM system. GitHub is a social coding service/host and may be directly compared (more or less) with Google Code, another social coding service/host.

Mercurial the SCM system may be directly compared to Git, another SCM.

As a developer, I prefer Mercurial to Git for a number of reasons, so I chose Mercurial for Spark/Plug and Escher. Since GitHub does not support Mercurial and Google Code does, I chose Google Code as the host.

For Txp 5, Mercurial+Google Code made sense because (1) Textpattern 4 is hosted on Google Code and it simplifies things for the devs to deal with a single platform for code sharing and deployment, and (2) Spark/Plug is on Mercurial and Txp5 will be built on Spark/Plug.

I understand (and agree) that GitHub is a superior social coding service to Google Code. However, my personal opinion is that Mercurial is a superior SCM to Git. Ideally, GitHub would support Mercurial (but then they would probably need to change their name).

If someone is truly interested in contributing to Txp5 development, I hardly think that the use of Mercurial/Google Code would be a reason not to get involved.

Regarding using a bridge, I have no experience with that. Philosophically I would not be opposed, assuming it results in no additional complexities for the devs to deal with. My hunch is that it would require support on the Mercurial side (i.e. Google Code would need to install a plugin, which is probably unlikely).

Last edited by artagesw (2012-01-10 19:10:22)

artagesw · 2012-01-10 18:28:33

philwareham wrote:

If we continue down the 4.x route and use Github I can very easily start improving the admin-side in my own fork, committing patches for approval at various milestones to the core.

And you could do exactly the same thing with Google Code/Mercurial. Mercurial is a peer-to-peer distributed version control system, just like Git, making it a simple process to fork the code, generate pull requests, etc.

thebombsite · 2012-01-11 19:07:41

I was going to write this over at textpattern.com but the comments thread is getting a bit long over there so it’s here instead.

As a very long-time user and abuser of Textpattern since the “gamma” days I’ve kind of grown up alongside it. As it has become ever better I have been able to produce sites the likes of which I couldn’t have dreamed of with something like WP, short of also becoming a PHP expert. So I write this from an experienced user’s perspective as opposed to the “coder’s” perspective of a developer/contributor.

I like Textpattern. I like it the way it is. I know there are various aspects which could, no SHOULD, be improved such as tables in the administration pages which shouldn’t be tables, custom fields which shouldn’t be limited to 10, categories which shouldn’t be limited to 2 (or maybe we should switch to tagging instead and make better use of that keywords field), a simple and STANDARD method of installing themes (which I have been working on myself, not built-in theming per se but a standardised method) and the standard admin themes which are a bit “20th century” (yes I know admin themes are easy to install but I bet you would be surprised at how many users out there simply can’t be bothered to learn how and also at how many potential users are put off by the current defaults and move on to something else).

So what does all the above have to do with this thread?

When the prospect of Textpattern 5 was first muted the idea was that it would be PHP5 – MySQL5 with no backward compatibility, thus Textpattern 5. Any user unfortunate enough to have a host which didn’t provide PHP5 or MySQL5 would have to stick with Textpattern 4, which would continue to be maintained and where necessary, particularly from a security point-of-view, updated. In the long-term it would be hoped that users would badger their existing host or simply move to a better one providing the requisite PHP/MySQL 5 requirements and Textpattern 4 could eventually be consigned to the archives.

Where did that idea disappear to? Suddenly Textpattern 5 was being built on a framework – Spark/Plug – and now there are suggestions that it should be built on another framework. Why do we need a framework? Why do we need to learn something else?

Although I am no coder one thing I do know is that the Textpattern code as it is now is light, robust and secure. Yes I know it could be improved in the various areas I mentioned earlier as well as others mentioned in other posts but to my way of thinking, considering how much time has passed already with no “installable” results to show for it, I would have thought that the current code could have been trawled through, updated and improved upon. And we would probably have something that we could USE by now.

So now I shall point directly at the elephant in the room that everyone else is trying to ignore.

For too long now the direction of Textpattern has been driven by coders. I have nothing against coders you understand. We bloody well need them don’t we? But I have thought that certain “ways of doing things” have been pushed by coders because it is the latest fad in coding methodology. Like, for instance, this “let’s build Textpattern on a framework” idea. What the hell is that all about? We haven’t needed a framework up to now and I haven’t heard a decent argument for using one now. Textpattern is unique in it’s small footprint and should remain so by not being reliant on someone else’s code as a basis.

And now we have another “coders’” argument about whether the code should reside on GitHub or Google and whether to use Git or Mercurial. To me it wouldn’t matter a jot except that I am already using TortoiseSVN and if Mercurial is used I will have to install and learn TortoiseHg. It’s no wonder “normal” users like me get put off the idea of using Textpattern, because at the end of the day “WE” are last in line to be thought about.

The result of all this is that I am still using Textpattern 4.

Instead of being driven by coders Textpattern’s future should be driven by it’s users. I know a lot of coders use it but you know what I mean. It’s no wonder we still have such a small user-base.

So there you go. I might not be thinking straight but at least I’m still thinking and I still use Textpattern, whichever version it might be. :)

maruchan · 2012-01-11 19:44:17

Wait, someone who sells Textpattern templates is not looking forward to a vastly improved version of Textpattern? :-)

Why do we need a framework?

Frameworks, done right, can save a ton of time. They can be the difference in having a feature you like, and not seeing it implemented, ever.

Why do we need to learn something else?

By “we” I’m assuming you mean “the developers”—the developers who are volunteering their time to Txp have stated that the old codebase is unsustainable insofar as new features are concerned. And we like our coders to be happy, do we not? :-)

Although I am no coder one thing I do know is that the Textpattern code as it is now is light, robust and secure

Agreed in part, but everybody wants it to be more featureful, easier to build upon, and more attractive to potential developers, do they not?

For too long now the direction of Textpattern has been driven by coders.

Extremely responsive, patient coders! They’re hardly dictators…

But I have thought that certain “ways of doing things” have been pushed by coders because it is the latest fad in coding methodology.

Like, for instance, this “let’s build Textpattern on a framework” idea. What the hell is that all about?

Save time, get new features for free, modernize the software, continue old traditions while attracting users who want the hot new thing, get more publicity and positive attention…these are all the upsides of this framework business.

The downside of the framework business is that it takes work (though certainly less than maintaining spaghetti), and if the documentation or support is at all lacking, you may find it impossible to win over a full development team.

We haven’t needed a framework up to now and I haven’t heard a decent argument for using one now.

To talk about starting a coding project without any kind of framework (application framework or content management framework, or even just one’s own favorite, tested way of doing things) in 2012 is likely a bit shortsighted. The framework technology is neutral though—have you considered that you may be more upset about the state of TXP5?

Textpattern is unique in it’s small footprint and should remain so by not being reliant on someone else’s code as a basis.

You’ve always got to rely on someone else’s something. Others might say you’re silly for relying on volunteer code for a CMS. A framework, too…it’s like getting years worth of coding experience for free.

And now we have another “coders’” argument about whether the code should reside on GitHub or Google and whether to use Git or Mercurial.

This is *huge*—youv’e got a gigantic pool of developers who already hang out on GitHub, where there are hundreds of other CMSes and frameworks in development, and you tell them they’ll need to use Mercurial…it really is a roadblock for many. Some will scorn it like an ill-advised career move, so strong are opinions on this issue.

The result of all this is that I am still using Textpattern 4.

Think about TXP5 being a fresh new thing that many end users really want to use, Stuart. You of all people could benefit enormously from an improved Textpattern!

If we keep our heads in the sand with Textpattern 4, it will slowly die anyway as developers find new fun things to do. TXP5 being fun (or at least not painful) for developers to work with is crucial.

Edit: Removed remarks that make me sound downright nasty :-)

Last edited by maruchan (2012-01-11 20:38:23)

artagesw · 2012-01-11 20:38:02

thebombsite wrote:

For too long now the direction of Textpattern has been driven by coders…

There is an important distinction that I feel you are missing. On the one hand, you have Textpattern form the user’s point of view (its user interface, feature set, etc.). On the other hand, you have Textpattern from the developers’ (including plugin authors) point of view (how the code is structured and built, how it is extended, what tools are used, etc.).

How the underlying code is developed (eg. whether built atop a framework or not) should be fairly invisible to the user, and frankly, is not a user concern (except insofar as the use of a framework both eases and speeds development of new features, which should make users very happy in the end).

Similarly, which SCM system to use is a developer concern. How many of Textpattern’s users fetch the software from SVN as opposed to grabbing the latest stable tarball from textpattern.com? Not many, I’d wager. And there’s no reason we cannot continue to mirror the code on SVN if there is enough demand to warrant it.

Regarding GitHub’s “millions of developers,” how many of these are chomping at the bit to work on Textpattern? Sorry, but putting Textpattern on GitHub will not suddenly bring an influx of new contributors to our project. The folks who have been hanging around this forum for the past several years asking to be involved are our best bet for quickly ramping up this project.

Stef has put out the call. We’ve put the code up in a distributed version control system that anyone can easily fork, contribute to, etc. Basically, we’ve done what the community has asked us to do. And all I’m hearing is complaints. Come on people…

gomedia · 2012-01-11 21:03:34

Sam, well said, but don’t be dismayed that we’re not all jumping in to help with the coding. For my part it’s a lack of time and too many other (usually client) commitments that prevent me from helping out. I know – the same old excuses!

And my feeling is that you guys (the devs) have climbed a very steep learning curve with all this – one that scares the hell out of us mere mortals.

For example, I got as far as installing a Mercurial app, cloning TXP5 & Spark/Plug, got a Table 'txp5_dev.txp_prefs' doesn't exist message … and then got waylaid with something else. Even the installation procedure breaks new (rough) ground.

You definitely have my moral support though, and my tuppence-worth, for what it’s worth.

thebombsite · 2012-01-11 21:35:16

except insofar as the use of a framework both eases and speeds development of new features, which should make users very happy in the end

But why Sam? That’s seems to be half the problem here. When you coders start chatting amongst yourselves in a thread like this I’m half lost. I understand some of it but WTF is a framework? Why does it make the developers’ lives easier? Why is it more flexible? Instead of throwing out general statements I for one would like some more detail if it isn’t too much trouble.

And don’t ever think I don’t appreciate what the developers do around here. I am more aware than most. I am also aware of what it is like to put in a lot of time and effort for no monetary reward only to find some sarcastic or derogatory comment about it in the forum.

A bit more detail for us “users” would be most welcome none-the-less. Just because I’m not a coder doesn’t mean I am not interested or that I don’t want to learn. Maybe I’m one of the few?

maruchan · 2012-01-11 21:53:02

Why does it make the developers’ lives easier? Why is it more flexible?

Have you used an HTML & CSS framework before, such as HTML5 Boilerplate, or Initializr? It usually takes every best practice you’ve read about in some blog post somewhere, puts it into an empty “template” for you, and then you can build whatever you want on top of that. There’s no need to reinvent someone else’s best practice every time you start a new project.

The same is needed for PHP coding. It’s why ExpressionEngine is built on the CodeIgniter framework. It’s why Drupal is starting to integrate the Symfony framework.

I wouldn’t say a framework necessarily makes things more flexible—you can argue that a completely blank slate is about as flexible as it comes. The time-saving element is probably a bigger deal.

michaelkpate · 2012-01-11 21:56:39

thebombsite wrote:

So now I shall point directly at the elephant in the room that everyone else is trying to ignore. For too long now the direction of Textpattern has been driven by coders.

I would respectfully disagree.

Textpattern 4, darling friends and beloved comrades, is now available. – Dean Allen, August 14, 2005

I would argue that the elephant in the room is that there we are really still on 1.0 of a Content Management System that began development 12 years ago. While 4.4.1 is certainly better than 4.0 and infinitely more secure, it isn’t fundamentally different than the version I first downloaded back in 2004.

I think we all agree that we want the Textpattern user community to grow and I am pretty sure it is going to take something like a 5.0 release for that to happen. Nothing short of that is going to generate enough buzz to get people’s attention.

Personally, I don’t care if we use git or Mercurial or even the venerable Subversion. I am just looking forward to things moving ahead.

joebaich · 2012-01-11 22:23:26

Like @thebombsite, I am a user and no coder. When I read Stef’s blog post of 7 Jan my heart sank and I felt as though I was staring at the great naked arse of an Emperor (not Stef’s backside, Hans Christian Andersen’s Emperor with no clothes). I slumped into the depths of despond and had a sleepless night as I fretted about an apparent lack of ~~clothes~~ progress. Textpattern is important to me because I have invested time and effort learning how to use it and have a bunch of client sites running it.

The next day I hoisted aboard Marc Carson’s and Dale Chapman’s replies to Stef’s post and snapped out of the despond. They were exactly right, nobody is getting paid to develop Textpattern and those that do, do it because they enjoy it. I then re-read most of this topic and point back to the its third post where Jeff Soo in his very first post as a dev explains very concisely and in terms that are easy to understand: why PHP5, why a framework (MVC), why OOP and why Spark/Plug. I had to Google MVC to find out that it was a type of coding framework. As a web site designer I know exactly what a framework is, I collect a new HTML/CSS framework every other day to play with.

So to @thebombsite I say “Courage, mon brave”! The Textpattern core and plug-in developers are doing an outstanding job. So there hasn’t been much palpable progress in developing Textpattern 5 in the last twelve months. Fact of life, let’s get over it. Textpattern 4 whatever is alive and well to keep us going for the present. As for the notion that users should drive the development of Textpattern, well that’s a bit like saying the passengers should drive the bus. Our role as users in all this is to define a user requirement, or more simply, state what we need doing. It’s not our job to tell the developers how to do it, that’s for them to sort out.

I was sad to see Walker Hamilton go off in the huff, I hope that he will relent in due course because he has does good work and is exactly the kind of high profile designer the community needs to fly a Textpattern flag at the sharp end.

thebombsite · 2012-01-11 23:28:10

I have plenty of courage Joe. No worries there.

So assuming the debate about whether a framework is used or not is done and dusted there still appears to be the question of which one. Spark/Plug is currently being used but is new and doesn’t appear to have everything required for Textpattern 5. That said it would seem that as something becomes required it is created. Am I thinking right there?

Marc C. then suggests the devs might want to look at processwire as it is already an up and running project and the project owner is keen too. It seems a logical suggestion as the devs would only need to develop Textpattern on top of it and not have to develop the framework as they go. Am I thinking straight there?

One advantage for processwire is that I have already downloaded and installed it. Seems a rather large download though. Ten times bigger than the current Textpattern. I know this includes a site so I’m assuming that for a framework we don’t need all of that. Maybe just the “wire” part? I should mention that It did install very easily with no need to create and upload a config file.

MattD · 2012-01-11 23:36:04

It looks to me like Processwire is a ~~CMS that Marc was saying he could move sites to INSTEAD of Textpattern or Escher. Not to build Textpattern on top of~~.

edit: I may have misunderstood what he said

Last edited by MattD (2012-01-12 00:18:09)

artagesw · 2012-01-11 23:45:46

thebombsite wrote:

So assuming the debate about whether a framework is used or not is done and dusted there still appears to be the question of which one. Spark/Plug is currently being used but is new and doesn’t appear to have everything required for Textpattern 5.

Like what? I built Escher, a very functional CMS containing many of the features Textpattern users have been asking for – all on top of Spark/Plug. Statements like this need to be backed up with specifics, so they may be properly addressed. Otherwise, they serve only to further fuel the flames of fear, uncertainty and doubt.

No framework does everything a given application needs. Otherwise users would run the framework alone, with no need of an additional application layered on top. By definition, a framework is a set of building blocks. That said, let’s not foget that Spark/Plug is authored by me, a Textpattern dev. And it has been developed with the creation of CMS applications (Escher, Txp) in mind from the start.

When the time comes that Textpattern needs some functionality added to its underlying framework, what framework author do you think will be more responsive to that need? The one who is also a Textpattern developer? Or one who has no vested interest in Textpattern?

Last edited by artagesw (2012-01-11 23:51:28)

tye · 2012-01-12 00:54:02

I’m not a coder and also get lost with talk of spark/plug, git, mercurial, mvc and all that mallarky – but I do know that the txp devs have always delivered a great product for me, a designer/user, and kept to the line of a lightweight/user friendly/powerful, flexible, elegant and easy-to-use CMS :) – so can’t see why they would change now

I have faith

Last edited by tye (2012-01-12 01:00:02)

Textpattern CMS

Textpattern CMS support forum

#256 2012-01-10 10:53:29

Re: The direction of Textpattern 5

#257 2012-01-10 18:26:33

Re: The direction of Textpattern 5

#258 2012-01-10 18:28:33

Re: The direction of Textpattern 5

#259 2012-01-11 19:07:41

Re: The direction of Textpattern 5

#260 2012-01-11 19:44:17

Re: The direction of Textpattern 5

#261 2012-01-11 20:38:02

Re: The direction of Textpattern 5

#262 2012-01-11 21:03:34

Re: The direction of Textpattern 5

#263 2012-01-11 21:35:16

Re: The direction of Textpattern 5

#264 2012-01-11 21:53:02

Re: The direction of Textpattern 5

#265 2012-01-11 21:56:39

Re: The direction of Textpattern 5

#266 2012-01-11 22:23:26

Re: The direction of Textpattern 5

#267 2012-01-11 23:28:10

Re: The direction of Textpattern 5

#268 2012-01-11 23:36:04

Re: The direction of Textpattern 5

#269 2012-01-11 23:45:46

Re: The direction of Textpattern 5

#270 2012-01-12 00:54:02

Re: The direction of Textpattern 5

Board footer