The direction of Textpattern 5

maruchan · 2012-01-26 16:44:28

Is MacHg any good, Phil? Wondering if there’s a worthwhile tool like the GitHub client.

philwareham · 2012-01-26 16:58:22

MacHg is miles behind the Github app in ease of use – but it is free and written by one person so I’m not disparaging it.

And while it’s tracking changes to files locally OK, I can’t seem to get it to push to Google Code successfully.

Not related, I also can’t seem to find a way to make a pull request from one Google Code project (my Textpattern5 fork) to another (the official Textpattern5 repo). Something that’s achieved with a couple of button clicks on Github.

6sigma · 2012-01-30 22:07:00

Did this discussion get continued somewhere else?

Did any of the following questions get answered or are they now marinating:

Rewrite or continue improvements?
Spark/Plug framework or no framework or other?
To Processwire or not to Processwire?
Mercurial vs. Github or other?

MattD · 2012-02-08 17:12:21

Interesting article I saw today about PHP Frameworks.

gfdesign · 2012-09-18 12:38:12

I’m not sure if this was spoken, but in during my experience with TXP since 2009 I’ve longed (and envied) a nestled comments system such as has Wordpress or Drupal for instance. It should be something indispensable because nowadays our favorite CMS doesn’t have such system and several clients have requested me when we use TXP for a blogging plataform. I’d like to see this in a new feature in TXP5. This is my two cents, I hope.
Warm regards

Last edited by gfdesign (2012-09-18 12:41:46)

AdamK · 2012-10-31 01:47:03

gfdesign wrote:

I’m not sure if this was spoken, but in during my experience with TXP since 2009 I’ve longed (and envied) a nestled comments system such as has Wordpress or Drupal for instance. It should be something indispensable because nowadays our favorite CMS doesn’t have such system and several clients have requested me when we use TXP for a blogging plataform. I’d like to see this in a new feature in TXP5. This is my two cents, I hope.
Warm regards

Regarding comments I believe it would be great to move all the comments subsystem out as a module/core level plugin and then provide user with choice (let’s say as an option in Preferences”): native comments, Disquis integration, FB comments integration etc.

then you would use something like <txp:comments_section /> in the article form, with the optional attribute ‘form=“comments_form”’ for styling local comments

A.

etc · 2012-10-31 08:25:15

Nested comments plugin is there. I have a little polished it, please comment here to see it in action.

Destry · 2012-10-31 08:56:14

AdamK wrote:

Regarding comments I believe it would be great to move all the comments subsystem out as a module/core level plugin and then provide user with choice (let’s say as an option in Preferences”): native comments, Disquis integration, FB comments integration etc.

+1

But I would propose doing this ASAP (4.6, 4.7…), not wait for the mythical TXP 5.

Native comments are increasingly undesired by people whose sites I help them with. More and more of my clients are becoming better with social media and want better integration in that direction. For all non-profit projects I work on, the organizations have Facebook groups too, and that’s where 95% of their social interactivity takes place, even for published articles. I see so many sites with FB, Disqus, or LiveFyre comment integration because it’s what people already use in other places on the web, and site owners want to tap into that with their ‘audiences’.

Removing comments from core would also be good for people (like me) who don’t want comments at all (another increasing trend), and would rather not see all the comments-related artifacts in the admin UI that I’ll never use. I want to avoid the code overhead, comment spam, and general ugliness that comments add to a site. And now that mobile is a factor in people’s lives anymore (even more than just two years ago), and with social tools pushing and pulling microcopy around now, conversation can easily be diverted six other directions and likely be better for it. I’m not using comments in my site relaunch (or ever again), but I still have to look at all this stuff in the UI for comments:

Preference controls in two different preferences panels.
A comments fieldset in the Write panel.
The Comments panel.
Non-deletable forms in the Forms panel.

(Am I forgetting somewhere?)

Sure, I can use a plugin to hide them, or mod the core to do the same thing, but neither should be necessary if you just don’t want comments at all. Opt-in, not struggle out.

Lastly, Txp comments have just never worked very well. For those rare projects now when I do use native comments, I need at least one other plugin anyway to get them to function half way decent so clients and their site visitors understand them. (I still don’t understand the implementation at .com). They might as well just be a plugin in themselves that works better, implements easier, and provides the other benefits of being a bolt-on option (cleaner UI if not used, freedom to choose what tool, and whatnot.)

Bloke · 2012-10-31 09:51:20

Officially noted, and has been brought up before.

Still not really sure of the best approach. Ripping out comments breaks backwards compatibility, but you’re right that comments don’t feel fully realised so they need sorting out in some manner.

Pulling all comment-related code into a single file would make things cleaner and offer the option to modularise it in future, but comments are rather ingrained in Textpattern’s operation (e.g. when saving articles, “Essential” Forms you mentioned, importing from other blogging platforms, tag builder, etc).

Hypothetically imagine if there was no txp_discuss table in the database and it was installed at will. How would a module/plugin hook into the core such that the core could “know” how to handle them? For example:

How would it know about updating the comment count if a new comment was posted from a core or third party system? (would it even matter?)
Would a comment trigger a “site is updated” notification?
How would they integrate with feeds?
How would the options to control comments be presented? (btw: the gripe about the comment prefs being in two places is already fixed in 4.6.0)
If you’d deleted the ‘essential’ comment Form(s) they would need reinstating if the implementation remained as it was today, or they might not be necessary if implementing a third party comment system.

And I’m sure a host more issues crop up. That’s what’s called “non-trivial” in my book.

The easy(ier) solution is to:

leave them as they are, but with better tag handling and less confusing options (possibly revisit the <txp:comment_* /> tag suite and simplify it or make it more usable).
turn comments off by default for new installations and retire Donald Swain.
when they are off, make sure every core UI component that relates to comments is removed so the interface is cleaner.
enhance the callbacks so it its easier for comment plugins to spring up and integrate with Textpattern.

I’d favour that approach but I’ve not fully thought it through. Anyone care to realign my thinking or offer alternatives and/or improvements? Perhaps in the Comment system thread?

Destry · 2012-10-31 10:08:53

Bloke wrote:

Officially noted, and has been brought up before.

I was only going to “+1”, but got carried away.

The easy(ier) solution is to…

Those all work for me. Especially #3. I guess third-party options could be unique plugins each, and if they worked while #3 was in effect, all the better. (E.g., Disqus has it’s own admin-side, so there’s no point trying integrate all of Txp’s specific comment controls with it. Likely the same with LiveFyre, but I don’t know about FB.)

I guess another option regarding backwards headaches would be 4.x/5.x fork. :)

Last edited by Destry (2012-10-31 10:11:22)

philwareham · 2012-10-31 10:27:35

Bloke wrote:

when they are off, make sure every core UI component that relates to comments is removed so the interface is cleaner.

While we are in a +1ing mood. I +1 this.

tye · 2012-10-31 23:27:51

I think comments have to stay

But more +++‘s for removing them from UI if turned off

Textpattern CMS

Textpattern CMS support forum

#289 2012-01-26 16:44:28

Re: The direction of Textpattern 5

#290 2012-01-26 16:58:22

Re: The direction of Textpattern 5

#291 2012-01-30 22:07:00

Re: The direction of Textpattern 5

#292 2012-02-08 17:12:21

Re: The direction of Textpattern 5

#293 2012-09-18 12:38:12

Re: The direction of Textpattern 5

#294 2012-10-31 01:47:03

Re: The direction of Textpattern 5

#295 2012-10-31 08:25:15

Re: The direction of Textpattern 5

#296 2012-10-31 08:56:14

Re: The direction of Textpattern 5

#297 2012-10-31 09:51:20

Re: The direction of Textpattern 5

#298 2012-10-31 10:08:53

Re: The direction of Textpattern 5

#299 2012-10-31 10:27:35

Re: The direction of Textpattern 5

#300 2012-10-31 23:27:51

Re: The direction of Textpattern 5

Board footer