populateArticleData() custom field handling

[ghost]

From netcarv...@gmail.com on July 23, 2009 15:06:12

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: http://code.google.com/p/textpattern/issues/detail?id=20

[ghost]

From r...@vanmelick.com on September 08, 2009 15:18:18

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)

[ghost]

From stefdawson on September 23, 2010 06:37:54

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

Status: Confirmed

[ghost]

From stefdawson on October 15, 2012 05:13:00

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.

Summary: populateArticleData() custom field handling
Status: Assigned
Owner: stefdawson
Cc: r.wetzlmayr
Labels: Milestone-4.6

[petecooper]

Should be covered by #456 in real terms, so closing for the moment.