Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Per-section article/comment syntax parsers
How do people feel about separately configuring the text parser used for articles and the text parser used for comments on a per-section basis? Right now the parser can be assigned only to articles and only on a site-wide basis (convert line breaks, use Textile, leave text untouched). I’m also not aware of an existing mechanism for dropping in new parsers. (Plugin help would remain Textile.)
I need this feature for a site I’m working on. I have written a special text syntax that is ideal for writing stories and poetry, and I plan to limit user comments to 250 characters and to containing only bold, italics, and linkified-URLs. But I’m also aware that some people have rigged Textpattern to use Markdown instead of Textile. It would be nice if Textpattern core supported this level of flexibility, allowing the site developer to select the syntax best suited for the application.
I’m trying to decide whether to just tweak my Textpattern installation to do exactly what I need or to put a bit more thought into a general solution that would be of use to others (and ease my upgrade process).
Are the guardians of the core open to allowing other syntaxes in Textpattern? I’ve been wondering whether it’s an unspoken mission for Textpattern to promote Textile to the exclusion of competing syntaxes (though in my mind the likes of a poetry syntax and a simple comment syntax aren’t competition).
If I get a sense that this is something people want and that the guardians of the core would be open to a clean implementation, I’ll code it up. Please send your input my way, including any tips you have on unobvious pieces that would need to change, parser APIs, DB schema mods, user interface mods, etc.
Thanks for considering my proposal. (Surely someone has made this proposal before — couldn’t find it.)
~joe lapp
P.S. I’m aware of some other blogging systems that assign the parser on a per-article basis. While this provides the ultimate in flexibility, it also creates a maintenance nightmare. What if you want to change the parser to some new superset parser that comes out? E.g., suppose you’ve been using simple text for your poetry and suddenly discover my poetry parser? Besides, it makes more sense organizationally to associate the parser with a section, all of whose articles are semantically analogous anyway.
P.P.S. I’m less certain about a per-section comment syntax. I need at least the ability to assign the comment parser on a site-wide basis, but the per-section flexibility doesn’t seem to hurt. Blog responders need more flexibility for articulation than people who are responding ‘nice’ or ‘yuck’ to artwork, and I’m not sure we’d want to force site developers to use distinct installations and databases to accomplish this.
Offline
#2 2006-03-20 05:23:15
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Per-section article/comment syntax parsers
Edit: this ability (customizable markup) has been much discussed and is forth-coming (“when” exactly that will be isn’t certain, except that it won’t be tomorrow). You can see the work being done in the “crockery” branch of svn.
As for “per section”, that is likely a little farther away.
Last edited by Mary (2006-03-20 05:33:27)
Offline
Re: Per-section article/comment syntax parsers
Oh, my apologies! Where’s the roadmap and feature spec, so I don’t embarrass myself again? I’d rather read the agreed-upon plan than infer it from the (presumably incomplete) source, if that’s possible.
I’m curious about the solution chosen if it isn’t per-section. I don’t want to restrict myself to poetry syntax across the entire site! Maybe it’s not too late for me to influence the outcome.
Thanks for the quick response!
~joe
Offline
#4 2006-03-20 07:27:38
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Per-section article/comment syntax parsers
Don’t feel embarrassed, just letting you know what “us regulars” already know from being around here long enough. Honest inquiry isn’t looked down upon ‘round here. :)
Now, there won’t ever be a roadmap (to the woe of those who like such documents, many a forum threads on that…), given that there is a small number of “official” developers (4) and they’re not paid to do it (so things get done when they can, after paid-for work is done, and so on). If you do a roadmap, you have to commit to release dates, and specific features for those dates, which just isn’t practical for this particular project.
As far as features, they typically get discussed here (sometimes they are “surprises” from the devs) and hashed out. Outside that, the source is truly open. For a quick peek at what’s being worked on if svn isn’t your thing, take a peak at this (this was checked in about 6 months ago).
It certainly isn’t too late to influence the outcome, given that this feature is in “crockery”. This forum’s moderators and/or enthusiasts can “show you around” as to how you can participate. :)
Offline
Re: Per-section article/comment syntax parsers
Great! Thanks! I’ll try to strike up a conversation with Zem.
It’s looking like I might get what I want and not have to much work. Can’t beat that!
BTW, Textpattern’s current tying to Textile is the main reason I attempted to use four other blogging systems before trying Textpattern. I knew with Textpattern that I’d be doing one-off tweaks. And the reason I’m sticking with Textpattern is the page-layout flexibility it offers me. I can even set my copyright date in the page footer to the year in which I wrote the story or poem (but the footer is in the article form).
~joe
Offline
Re: Per-section article/comment syntax parsers
Eeeks!
In the process of fitting my new parser into Textpattern, I just learned that Textpattern is storing the parsed text in the database. That maintenance nightmare I was suggesting we avoid is already here!
With a proper staleness-based caching system (such as asy_jpcache), there’d be no need to parse the text at edit time. Even a 3-second staleness window would be indistinguishably equivalent.
Also, changing the default article syntax and then resaving previously saved articles doesn’t change the parser used — it remains Textile. I can’t find a FAQ item to help. Do I really have to delete and re-enter the article? Thanks!
~joe
Offline
Re: Per-section article/comment syntax parsers
In retrospect, maybe it’s not possible to avoid the maintenance problem and change the parser on a section-wide basis. Someone may use Textile for umpteen articles before deciding to switch to Markdown in the same section, so you’d have to know which article used which parser. I guess I better dig into the crockery source to find out what’s going on. (But it would still be nice to default each article to a parser on a per-section basis.)
I’ll report back with what I find in the crockery. Thanks again!
~joe
Offline
Re: Per-section article/comment syntax parsers
Me again. I just examined the crockery source. Here’s the current scoop:
(1) The parser can be selected on a per-article basis.
(2) Comments remain hardcoded to use Textile.
I’m very happy with (1), but would prefer the ability to assign the comment parser on at least a site-wide basis. I want to limit input to 250 characters and greatly restrict user formatting options. Then again, the 250 character restriction ought to be imposed on the textarea input so the user can’t type more than 250 (and receive a surprise truncation), even if it’s not possible to enforce it there. (I pointed zem to this thread, didn’t know where else to hold the conversation.)
I tried to install the crockery source, but although it succeeded in creating many DB tables, it also bombed on about a hundred queries during the installation process alone.
~joe
Offline
#9 2006-03-20 23:06:06
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Per-section article/comment syntax parsers
In the process of fitting my new parser into Textpattern, I just learned that Textpattern is storing the parsed text in the database.
You should also notice it stores the raw text as well.
Also, changing the default article syntax and then resaving previously saved articles doesn’t change the parser used…
Yes, it does, it’s always done that.
I tried to install the crockery source, but although it succeeded in creating many DB tables, it also bombed on about a hundred queries during the installation process alone.
FAQ: How do I fetch the current development version?
/development/crockery/ – this is our playground for the next major release (4.1). Anything goes here: it’s experimental, unreliable, and subject to change. Do not use this for a live site, don’t point it at a live database, and don’t expect it to work perfectly (or at all).
Offline
Re: Per-section article/comment syntax parsers
Hi Mary,
You should also notice it stores the raw text as well.
Yes, that’s what threw me at first. When you edit the article, you get the original raw text.
Yes, it does, it’s always done that.
Not sure if you’re saying “Yes it doesn’t update the parser on re-save” or “Yes it does update the parser on re-save.” 4.0.3 wasn’t updating the parser on re-save. I did an SQL update on the DB to force the change, and then I resaved each article to reformat it in the new format. That worked.
Regarding your FAQ quote, thanks, I was aware that it’s all experimental and not likely to work. However, I was a bit surprised that it wouldn’t install. I assumed that the develoeprs are actually running the thing, if they’re posting mods to it. Maybe they are and are updating the installation without yet testing the installation. That would explain it. In any case, I’m not complaining, just posting a caveat “but I didn’t actually run the cockery.”
Thanks!
~joe
Offline
#11 2006-03-21 07:14:47
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Per-section article/comment syntax parsers
Tried and true, Textpattern saves your markup setting and re-parses your content with every save. If it doesn’t, something is wrong, and you need to troubleshoot. Are you sure you were actually saving each time? If you didn’t click the red button, it wasn’t saved.
They do run it, but it won’t always be in a perfect state of completeness. You’re seeing real experimentation and testing, not already perfected code for public consumption. When they say “experimental, unreliable… and don’t expect it to work perfectly (or at all)”, that’s exactly what they mean. :)
Offline
Re: Per-section article/comment syntax parsers
Hi Mary,
Maybe we’re talking about different things? Here’s the procedure that doesn’t behave as I originally expected:
(1) Set the parser to Textile.
(2) Enter a new article X.
(3) Change the parser to “none.”
(4) Pull up X and save it again (or pull up X, change it, and then save it again).
No matter what I do, X remains parsed by Textile rather than not parsed (by “none”).
But yes, any changes I make to the raw text are saved and reformatted into HTML, but they do so using Textile.
It’s not clear that it should behave any other way, since txp doesn’t know whether I’m merely changing the content for reformatting by the originally designated parser or whether I’m changing the entire syntax for reformatting by the most recently designated parser.
I believe the crockery version will solve this problem, since it seems that the plan is to allow the parser to be selected (and re-selected) on the article entry form itself.
Does that make more sense? It almost seems right that I had to issue an SQL update to change the format of an article in 4.0.3 (an explicit user action is needed to do the job).
~joe
Offline