The direction of Textpattern 5

philwareham · 2012-01-10 10:32:51

Please please please can we reconsider using Github for developing Textpattern 5 (or 4 or whatever number you finally decide on) instead of Mercurial. Or implement a Git-Mercurial bridge (yes they exist).

If, as Stef points out in his latest blog, you want lots of contributors – then Github has a millions of users that understand it and use it everyday. I’ve seen countless other requests to rethink using Github from other potential contributors. I don’t work for Github by the way.

Last edited by philwareham (2012-01-10 10:33:56)

Bloke · 2012-01-10 10:42:36

philwareham wrote:

Please please please can we reconsider using Github for developing Textpattern 5 (or 4 or whatever number you finally decide on) instead of Mercurial. Or implement a Git-Mercurial bridge (yes they exist).

Sure. I don’t care where it is as long as I can develop on it. I didn’t know about the bridge thing: thanks for the heads-up.

When the Txp 4/5 dust settles I’ll do what I can. Or at least find someone who knows what they’re doing and can do it for me :-)

Last edited by Bloke (2012-01-10 10:45:14)

philwareham · 2012-01-10 10:52:49

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.

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.

Textpattern CMS

Textpattern CMS support forum

#253 2012-01-10 10:32:51

Re: The direction of Textpattern 5

#254 2012-01-10 10:42:36

Re: The direction of Textpattern 5

#255 2012-01-10 10:52:49

Re: The direction of Textpattern 5

#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

Board footer