Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Privatize content per user
jayrope wrote #310044:
etc, i suppose that wouldn’t work long. It smells like too many double entries for the same content in the database all too soon – here on a multi-user site basically sharing content of partly mutual artist or business or press connections.
At worst, it’s one mostly empty hidden article per user, that the user will clone (thus inheriting its private fields) with a click and edit when he needs to write a new article. Actually, it’s one hidden article per user group with identical privacy settings.
I agree that’s not ideal, but you’ll need to store these per user settings somewhere anyway. And as a bonus, you can store other shared data (section, category) for free.
Offline
Re: Privatize content per user
jayrope wrote #310043:
note: for 4.8.
Is there a release roadmap, also for 4.7? Wrong thread i know, but it’s good news, that it is possible!
v4.7 is imminent (the beta is out) so I wouldn’t expect new features of that degree for v4.7.
If glz_cf gets updated for 4.7, eventually it is more simple to incorporate this into the plugin instead of the core. If the plugin had two more entry sections in the database, essentially marking first, if a certain CF is generally private or not, clickable by a tick next to the custom field in the write form, and then extends to a per-author panel in admin allowing individual authors to provide access to individual other users, then most is accomplished already.
glz_cf is already updated for 4.7: see here.
But unfortunately what you suggest is not within the scope of it. This isn’t being awkward or stubborn, but there are two good reasons:
- glz_cf uses the current custom field mechanism to add new custom fields which is really just a preference so limited; and it’s own ‘custom_fields’ table for custom fields with multiple values but it is not a row per custom_field to which you could add the necessary extras but a row per multiple-choice value; and textpattern’s language tables for field titles. None of those offer the scope for attaching further custom field metadata such as owner and one-to-many readability states for different other users, so what you’re suggesting would mean adding further tables and input variants adding further layers of complexity.
- glz_cf should be superseded by the core implementation, so I hope it will be made redundant with the next version of textpattern. My aim was to make glz_cf work reliably again and be compatible with existing glz_cfs. Gerhard’s original concept has a fundamental flaw/limitation in the way it stores custom fields that the core implementation will aim to overcome, so I wasn’t planning on making it indispensable in future.
That said, I still think the suggestion I made above to do your own custom_script custom field could be workable if you’re willing to slightly simplify your scope a little to setting certain custom_fields as potentially private for everyone and limiting display according to smd_um user privs level instead of making every custom_field potentially privately viewable for individually named other users, which requires a whole pick and choose interface per field, and that the users update it when new users join.
Regarding etc’s trick of outputting the custom_field via tag, here are two more ideas. The write panel has an option to hook into the save article routine before committing to the database. That you could use to either:
- strip out any txp: tags in the body field so that if other users put a txp:custom_field tag in their article body or excerpt, it would be stripped out before saving.
- to encode your chosen private fields on saving so that even if people could output it, they get only meaningless letter-soup. Only your own page template code (non-public) and your custom_field custom_script (also non-public) should know how to read that back out as normal readable values.
If you want to investigate that further, glz_custom_field hooks into article_save to group multiple choices (such as check boxes) into a string before saving, so you could look at that for pointers, e.g. here and here.
TXP Builders – finely-crafted code, design and txp
Offline