populateArticleData() custom field handling

[GoogleCodeExporter]

Problem
=======

Currently populateArticleData() adds the custom fields to the $thisarticle
array using the label the administrators setup in the advanced preferences
page. However, no checking seems to be done to determine if the user's
chosen field name is already used by textpattern. This can give rise to
some confusing scenarios.

If a user were to name one of their custom fields such that the name
matches an existing field of the $thisarticle array, then that value is
overwritten by the value of the custom field, potentially leading to
unpredictable behavior and potentially support issues.

For example, if you create a custom field named 'body' then all existing
data in any article's 'body' field becomes hidden -- overwritten by the
value of the corresponding custom field. 

Proposed Solution
=================
The populateArticleData() routine should add the custom field values to
$thisarticle array in a segregated namespace (perhaps as simple as one
created by prefixing 'cf_' to the start of every custom field's name.)

The custom field tags would also need adapting to fetch field values from
the namespace too.

I'd suggest adding a single routine to the txplib_misc.php file to provide
a standard implementation for this 'name' => 'custom name' mapping and that
this function be used internally by populateArticleData() and the custom
field tag handlers. 

Impact on Plugins
=================
Custom field accessing plugins will probably need to be modified.

Original issue reported on code.google.com by netcarv...@gmail.com on 23 Jul 2009 at 1:06

[GoogleCodeExporter]

Another solution would be to use the actual table column names (custom_1) 
instead of
the user-defined labels for those columns. If you want to sort on custom 
fields, you
have to use those table column names anyway and it solves problems with labels 
as
shown below, not to mention the fact that it would get rid of some ugly hacks to
actually get the labels working properly on the public side:

'custom_1' => "spaces, i haz 'em"

<txp:article custom_1="something" /> (OK)
<txp:article spaces, i haz 'em="something" /> (FAIL)

Original comment by r...@vanmelick.com on 8 Sep 2009 at 10:18

[GoogleCodeExporter]

On the radar. Will defer this topic to TXP 5 when custom fields are revisited 
as part of a wider enhancement.

Original comment by stefdawson on 23 Sep 2010 at 1:37

• Changed state: Confirmed

[GoogleCodeExporter]

Roll in as part of the Key/Value store (see Issue 275 and Issue 277).

Subtext: custom field key *names* to be sanitized so they can be used in 
txp:article_custom, provided the names don't clash with existing attributes or 
table columns. A well-known prefix would do.

Possible option to enhance article_custom to use custom_n= attributes as well, 
depending on the way the key store is implemented.

Either would be a boon for multi-lingual implementations.

Original comment by stefdawson on 15 Oct 2012 at 12:13

• Changed title: populateArticleData() custom field handling
• Changed state: Assigned
• Added labels: Milestone-4.6