Textpattern CMS

#25 2006-07-01 06:36:26

wet

Developer Emeritus

From: Schoerfling, Austria

Registered: 2005-06-06

Posts: 3,323

Website Mastodon

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.

#26 2006-07-03 12:24:57

graeme

Plugin Author

Registered: 2004-06-21

Posts: 337

Website

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.

---

gbp_permanent_links | Multi-Lingual Publishing Pack | GitHub | Twitter

#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