[mention] Wordpress < > Textpattern

philwareham · 2011-01-17 12:23:46

Bloke wrote:

jsoo’s default template idea (on install)

Is there a link to what this is, I’m intrigued to find out any developments so far?

Cheers,
Phil

Bloke · 2011-01-17 12:36:22

philwareham wrote:

Is there a link

Sure — buried among the ideas on the first page of that thread before it started going off at a tangent. I’m not sure how far it got — I believe Jeff had a proof of concept up and running somewhere but he’ll be able to tell you more. I thought it was a great idea and if there were packaged themes easily available (as ~cXc~ seems to be advocating) then one could easily see people rolling their own TXP installs by uploading some packages along with their core files and just choosing one on install. And using the template manager plugin to switch themes further down the line.

Maybe hosted TXP services can then come of age…?

The on-install option would also be great for people (like me) who customise their installations and delete fluff, set up standard Templates and Forms, etc. I could make a template and save it as my baseline. Bliss. (EDIT: I know there are ways to do it using cnk_versioning or merging files into the core but it’s more hassle than I’m prepared to put up with).

Last edited by Bloke (2011-01-17 12:38:00)

jsoo · 2011-01-17 14:17:09

Bloke wrote:

I’m not sure how far it got — I believe Jeff had a proof of concept up and running somewhere but he’ll be able to tell you more.

I haven’t done anything with it since submitting it to txp-dev — there were no responses, a pretty good indication of lack of interest ;), and what people really want is public-side theme switching on existing sites, not just during installation. But I still have the code, of course, if it would be useful. It was only ever conceived as something to use if either:

there were no plans for an integrated public-side theme switcher, or;
there are such plans but a stop-gap is needed.

hcgtv · 2011-01-17 14:21:03

Bloke wrote:

Perhaps with ~cXc~’s new template system and jsoo’s default template idea (on install) we can really start to tackle this area.

Any template system via a plugin has to deal with the core issues that I brought up almost 4 years ago, and hard coded forms have to be dealt with. A plugin can go so far, the core has to meet it halfway.

Bloke wrote:

The on-install option would also be great for people (like me) who customise their installations and delete fluff, set up standard Templates and Forms, etc. I could make a template and save it as my baseline. Bliss.

Following the Debian analogy, Debian being the basis for so many distros, due to it’s slow methodical upgrade process, I’m using Textpattern core to roll my own version. After following Textpattern for so many years, I’ve come to the conclusion that you have to roll up your sleeves and have at it.

Bloke · 2011-01-17 14:46:40

hcgtv wrote:

Any template system via a plugin has to deal with the core issues

Yep. Taking a digital AK-47 to the existing hard-coded Pages and Forms (on new installations) is part of the new public-side default template goals.

Comments should, imho, be relegated to a (core-sanctioned) plugin that you can choose to include during install or add later. The vast swathe of comment tags and comment forms need serious pruning. Whether these happen or not will be down to resources. Perhaps it’ll all come out in the wash when we’ve figured out a few more details.

I raised a thread ages ago on possible avenues of approach for the comments system but forgot about it and let it fall by the wayside. Might be outdated now but I think Gocom made a start on some refactorisation of the core comment tags.

maverick · 2011-01-17 15:03:34

Bloke wrote:

Google Code doesn’t appear to allow both that and SVN at the same time, and we’re not sure of the impact on the existing repos if we start a new repo using a different system.

If Mercurial is preferred for going forward, and the desire is to stay with Google Code, why not convert the existing repos to Mercurial as well?

Bloke · 2011-01-17 15:16:24

maverick wrote:

why not convert the existing repos to Mercurial as well?

This sentence: “If want to migrate your whole history, the process is much more involved” scares me and sounds like a lot of work, compared with leaving the existing repos alone and starting a new one somewhere else :-)

maverick · 2011-01-17 15:40:52

Bloke wrote:

Comments should, imho, be relegated to a (core-sanctioned) plugin that you can choose to include during install or add later.

In the past I was nervous when this idea has been suggested.

Minor: It meant yet another plugin
While commenting may not be a universal need, it seems too important to risk letting it fall by the wayside of neglect

However, I’m completely supportive of the idea these days.

As noted in other threads, Textpattern is meant to be a broadly focused CMS, not just a blogging CMS. Not every one needs comments.
Commenting is part of the core, but hasn’t received a lot of attention anyway (not a criticism – just an observation). So being part of the core doesn’t guarantee active development.
A basic core-sanctioned plugin means at least basic functionality will continue
I already usually add several plugins to make commenting more powerful/useful on sites requiring comment functionality.
If Txp’s core was refactored to enable robust feedback plugins, we are more likely to see several other plugins pop up – with different capabilities, etc. I can envision (but not code) a plugin that could make comments robust enough that it could be used as a light weight forum. (I know there’s some code out there already to that end ;) ).

So, Stef, I hope the you guys go for it on this change.

Last edited by maverick (2011-01-17 15:42:09)

maverick · 2011-01-17 15:47:41

Bloke wrote:

compared with leaving the existing repos alone and starting a new one somewhere else :-)

fair enough :-D

Enough of our active plugin developers are on GitHub, I’m sure that has come up, and offers synergies. So moving from Google Code to somewhere else is promising.

But I’ve read that for those on Windows platforms git is not as good of an experience as Mercurial. Which is a drawback I’m assuming (since one or more of our devs are on Windows)?

Last edited by maverick (2011-01-17 15:48:32)

Bloke · 2011-01-17 16:01:52

Continuing your list:

6. A commenting plugin would mean that other plugins could more easily be used instead of the core version if somebody wanted to come up with a stonking commenting system to perhaps do what you suggested in (5). That would also keep the posse who claim they can’t live with trackback happy as they could roll their own.

I’ve no idea if such a core-sanctioned commenting idea will come to fruition as there are a large number of factors to consider (for example, some semblance of backwards compatibility, time/desire to code it when it already works¹, etc). But as I say, things may fall into place.

¹ this is a rather subjective term :-D

P.S. your mention of a forum reminds me that one day I should tidy up and release the refactored TXPhorum code that we worked on for a project. It’s pretty neat.

Last edited by Bloke (2011-01-17 16:03:06)

hcgtv · 2011-01-17 16:40:08

Here’s a good article on the merits of Git vs. SVN, by the author of Pro Git.

As for Windows support, most IDE’s have built in support for Git already, I know my Komodo IDE has a plugin, and honestly, the command line tools are simple.

What I envision with a system like GitHub is that rather than have people submitting patches or working on stuff on the side, which may never see the light of day (news to me that Gocom has refactored commenting), these project contributions can be branches where they can be pulled into the master when and if they prove to be worthwhile core additions.

Bloke · 2011-01-17 16:46:02

hcgtv wrote:

rather than have people submitting patches or working on stuff on the side… these project contributions can be branches where they can be pulled into the master when and if they prove to be worthwhile core additions.

fwiw, that’s how I’d prefer to work too. Just gotta set it all up on our repo of choice (I’m not doing that bit). Some stuff to iron out first though, hence the delay.

Last edited by Bloke (2011-01-17 16:47:48)

maverick · 2011-01-17 17:06:36

Bloke wrote:

6. A commenting plugin would mean that other plugins could more easily be used instead of the core version

That was what I was trying to get to in my overly wordy manner. You were much more articulate than I! :)

I’ve no idea if such a core-sanctioned commenting idea will come to fruition

Understood. Just wanted to add support to the idea.

I should tidy up and release the refactored TXPhorum code that we worked on for a project. It’s pretty neat.

Cool!

ruud · 2011-01-18 12:49:54

Bloke wrote:

This sentence: “If want to migrate your whole history, the process is much more involved” scares me and sounds like a lot of work, compared with leaving the existing repos alone and starting a new one somewhere else :-)

The advantage of migrating the whole history is that it makes it easier to track why a certain change was made in the past, which can be helpful in understanding what a particular piece of code is/was for (I’ve used “svn blame” quite a few times for that purpose). One could argue that this could also be done by documenting the code better.

hcgtv · 2011-01-18 13:38:19

ruud wrote:

One could argue that this could also be done by documenting the code better.

That would be great, more is better even though some documentation exists on a per function basis.

How about a would be programmer’s cheat sheet?

a) Database reference – Textbook – my version.
b) The Textpattern flow, index.php calls foo.php, etc.
c) An explanation of what’s where and what it does (include is the admin area).
d) If we’re doing c. why not add an explantion to each php file – as per ruud’s suggestion.

Yes, if you work with the code long enough you end up figuring things out, but it’s time taken away from productive work if you want to start contributing. I may knock WordPress here and there, but their code is very well documented.

Edit: Wordpress to WordPress dangit.

Last edited by hcgtv (2011-01-18 13:50:54)

Textpattern CMS

Textpattern CMS support forum

#16 2011-01-17 12:23:46

Re: [mention] Wordpress < > Textpattern

#17 2011-01-17 12:36:22

Re: [mention] Wordpress < > Textpattern

#18 2011-01-17 14:17:09

Re: [mention] Wordpress < > Textpattern

#19 2011-01-17 14:21:03

Re: [mention] Wordpress < > Textpattern

#20 2011-01-17 14:46:40

Re: [mention] Wordpress < > Textpattern

#21 2011-01-17 15:03:34

Re: [mention] Wordpress < > Textpattern

#22 2011-01-17 15:16:24

Re: [mention] Wordpress < > Textpattern

#23 2011-01-17 15:40:52

Re: [mention] Wordpress < > Textpattern

#24 2011-01-17 15:47:41

Re: [mention] Wordpress < > Textpattern

#25 2011-01-17 16:01:52

Re: [mention] Wordpress < > Textpattern

#26 2011-01-17 16:40:08

Re: [mention] Wordpress < > Textpattern

#27 2011-01-17 16:46:02

Re: [mention] Wordpress < > Textpattern

#28 2011-01-17 17:06:36

Re: [mention] Wordpress < > Textpattern

#29 2011-01-18 12:49:54

Re: [mention] Wordpress < > Textpattern

#30 2011-01-18 13:38:19

Re: [mention] Wordpress < > Textpattern

Board footer