You are not logged in.
Heck, maniqui, and I thought I wrote long posts
Hehehe, “inspiration will find you working” could be “inspiration to avoid working will find you working”.
Instead of doing what I have to do, I start to think this great ideas and then I can’t stop.
In fact, when I was writing the post, I thought: “this will be longer than any post by Bloke”. But this isn’t also my first inspired post (and it isn’t the first one rejected, hehe).
OK, if both of you are not convinced by my ideas, at least I’m convinced by yours…
Well… I have this another great idea: avoid posting great ideas for a while.
We can start discussing this: http://notes.wetzlmayr.at/textpattern:relaunch:should-textpattern.com-match-the-template
La música ideas portará y siempre continuará
Hi maniqui, I think your idea for MLP sounds great, except for the practical problems for new users. But I don’t know anything about MLP, having never needed it, so what do I know? Perhaps it could be incorporated in the new txp.com with a disclaimer attached, or perhaps not. Perhaps it’s better to point to sites that use it successfully.
As a user who knows MLP well, would you like to write an article about it on TXPQ? Some details about how wonderful it is and some explanation of setup, possible problems etc. Also links to some sites using it. It will help you spread the word and give a good understanding that must be difficult without reading a very long forum thread.
TXPQ Examples and discussion of Textpattern CMS quality.
Added a couple of bits about SEO placement to try and at least put us on the radar. Help out if you can in the discussion on the right sort of search terms
Added some thoughts to this page. I would really like to contribute to the content side, since I think half of these issues people have is how the product is positioned and marketed to the rest of the world.
MLP isn’t a plugin, it’s a hack.
Agreed, it is a hack.
But should TxP.com be multilingual? Is it something the devs would like? If so, I would be willing to try make MLP less hacky.
@ ruud, zero, Bloke
The questions are:
Does TXP need a multilingual site or not? Wouldn’t it be beneficial for TXP itself? (main questions, if the answer is “no”, then skip this post)
I’m a newcomer, I’m looking at TXP.com for the very first time, I notice (or don’t notice) that the site is multilingual. If I notice the site is multilingual, I would think: “cool, this TXP thing does multilingual sites, although right now (or maybe never) I won’t need this feature”.
How is that confusing for newcomers?
Newcomers don’t know nothing about MLP, so they don’t know if it is a plugin or a hack or if it is built-in on TXP.
They will just notice that multilingual sites are possible with TXP. How? Well, if they need a multilingual site, they should investigate and learn how to do it. And, BTW, MLP is not the only way of doing a multilingual site with TXP.
I still owe you a reply to another email (sorry). I’ve started to reply to it a month ago, and there it is: still saved as a draft.
About writing an article about MLP, give me sometime, I’m really bad at writing ideas (if you don’t believe me, re-read my long post, hehehe).
No, really, I would like to, so, I will try to. Thanks for inviting me (again) to collaborate with TXPQ.
La música ideas portará y siempre continuará
But should TxP.com be multilingual? Is it something the devs would like?
The “facts”, as far the access log reveals them:
So, without any disrespect for non-english visitors, I’d rather allocate resources elsewhere.
If so, I would be willing to try make MLP less hacky.
MLP being less hacky would be appreciated anyway, and I’d like to add that we would glady introduce unobtrusive hooks/extensions/callbacks into core which helps with that goal.
we would glady introduce unobtrusive hooks/extensions/callbacks into core which helps with that goal.
Trying not to go too off-topic, would this tiny patch be one you would consider to help the de-facto gold-standard glz_custom_fields work without modification to the core?
I’m not sure if it falls under the banner “unobtrusive” (depends on how resource intensive preg_grep is) but it is only 3 lines of code :-)
Extending the number of columns in txp_textpattern is the wrong approach. This should be solved by moving the custom fields to a separate table, not by making the existing table layout even worse.
Extending the number of columns in txp_textpattern is the wrong approach.
/bloke confused. Didn’t know glz_custom_fields did that. Thought it used its own table for anything >10 and that all the patch did was allow the txp_prefs table to return custom_set_11, custom_set_12, etc instead of stopping at 10. *shrug* I must have got it wrong, sorry.