Sorry, we don't support your browser.  Install a modern browser

Transform value: access also store value in foreign key column#447

The Transform value feature is absolutely great, however I’d like to suggest a minor improvement, which would make a huge difference regarding its use in foreign key columns.

With all the placeholders currently being for the display values, in case of foreign key column there would be a separate placeholder for both store value (the “id”) and display value.

In addition to being able to reasonably achieve the very useful “see also” functionality (adding a link to the master-detail page of another row), I think there would be numerous ways to make use of the store value.
For example a product database having a column for a successor/replacement link, to be filled in (selected from a list) when the actual product is discontinued.
And all this with a convenient user experience for the users editing the table, no need to handle any product id numbers or URLs, hence the foreign key column approach.

In general, there would be so many possibilities especially for generating any item URL links, so that the store value becomes the item id part of the actual URL and the display value is used as the link text. Therefore both values would need to be accessible within Transform value settings.

Only for the sake of example, a Transform value code snippet that would be possible (here using pseudo code), for constructing a link to a wpDataTables feature suggestion:
link target = https://features.wpdatatables.com/ {placeholder for store value} text = {placeholder for display value}
So, in this foreign key colum, the users would choose from the suggestion titles, and both the title (the display value) and the id of the suggestion (the store value) would be passed on as a value pair for use separately in Transform value column, effectively creating a link to the chosen suggestion.

It should be noted however, that this suggestion would obviously benefit highly if #446 was possible in full, but currently a workaround is to have the needed foreign table values inputted manually by an admin or preferably populating them using SQL triggers or other automated database operations. The choice of method depends at least on the number of needed values and if values need to be added/modified/removed frequently or not.

24 days ago