Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: r1303: thisarticle changes
The other alternative is an i18n stub layer in the core code, to which extent ever as gTxt does this for the back end.
Offline
Re: r1303: thisarticle changes
wet wrote:
The other alternative is an i18n stub layer in the core code, to which extent ever as gTxt does this for the back end.
Not just useful for i18n/l10n. It opens up many possibilities.
For example. I’m working on a site at the moment for a small newspaper, where there are too many people writing content and it is not possible to expect everyone to upload their articles, mainly because its been written elsewhere so it ends up being uploaded by a different person. I’ve created a custom field for the real author. If the were callback events then it would be able to change the author to the correct person.
Or how about a plugin which wishes to extent the number of custom fields, with a little DOM scripting and a callback event the new fields would be available to every plugin author to use.
Two simple examples, I’m sure there are many more elaborate possibilities and advantages to this.
Saying that, I can see why sometimes you wouldn’t want to have modified content. How about having an extra attribute to populateArticleData()
something like:
function populateArticleData($rs, $allow_override = 0)
It won’t change to the current behavior unless the developer knows about it. It could even be a preference letting the site admin decide wether or not to to allow it.
Offline
#27 2006-07-04 00:29:55
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: r1303: thisarticle changes
If the were callback events then it would be able to change the author to the correct person.
There are already callbacks you can use to do this when an article is saved. And a plugin that lets you change the article author.
Or how about a plugin which wishes to extent the number of custom fields, with a little DOM scripting and a callback event the new fields would be available to every plugin author to use.
Also already possible.
I don’t see how either of these are related to the i18n issue.
Alex
Offline