Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
Multiple authors, single article
This has been discussed before but I still haven’t found a satisfactory solution. My website has multiple authors who occasionally co-author an article. Is there anyway to assign more than one author to an article? For now just two will suffice, but I can foresee future instances in which an article may have several co-authors.
Offline
Re: Multiple authors, single article
I’ve just worked out a solution for my site and I thought this might be helpful for others.
My workaround method is to use a custom field. It helps to have glz_custom_fields for it’s convenient multi-select fields (allowing several co-authors for one custom field).
Either way simply use an <txp:if_custom_field> tag to check that your “Co-Authors” custom field has a value and a <txp:custom_field> tag to return it alongside the code that ouputs the article’s assigned author. In my case, because I want each author’s name to be an anchor for listing that author’s posts I had to specifically list my authors in my form thus:
<txp:author link="1" />
<txp:if_custom_field name="co-authors" value="Mark Mesaros">, <a href="/author/Mark+Mesaros/">Mark Mesaros</a></txp:if_custom_field>
<txp:if_custom_field name="co-authors" value="Matthew Mesaros">, <a href="/author/Matthew+Mesaros/">Matthew Mesaros</a></txp:if_custom_field>
Most of that code would be unnecessary if I could use a <txp:author /> tag to return a specific author. And of course if you don’t care about using the author name as an anchor it’s very simple.
Offline
Re: Multiple authors, single article
Running into a situation for an important collaborative effort where any number of “contributors” and “affiliations” (no lead authors, exactly) could be attributed to a given article. The idea is to be able to structure the resulting output with RDFa/schema.org somewhat as described here (though the semantic parts will be a little different).
Adding code blocks like that inside of an article would be nuts, of course, and tedious to manage. Not going to happen.
Slightly better would be to use custom fields but not if restricted to 10. At the same time, I’d rather not install a quasi-supported plugin to extend the number at this point when the future looks better for handing this in core. (Unless said quasi plugin is expected to import to the core functionality relatively well, which I’m doubtful of.)
I haven’t looked at the roadblock (heh) but I guessing the custom fields extension work isn’t slated for 4.6. Yes?
In fact, as I think about it, custom fields isn’t a feasible solution here either. Maybe I need four or so different types of data per collaborator… but what if there are 20, 50, 100+ collaborators, as example. Nuts.
Another option is to give contributors Txp accounts, and pull the data via smd_user_man / smd_bio wizardry, but I’m still not sure how I could assign users on an article by article basis, logically tying multiple user accounts to a single, common article, but by some pick and choose process.
Any suggestions how to handle something like this?
How is anyone supposed to feasibly structure collaborative documents if there’s no way to dynamically build the semantic assignments? Tough one.
Last edited by Destry (2016-05-18 17:30:54)
Offline
Re: Multiple authors, single article
Destry wrote #299142:
Unless said quasi plugin is expected to import to the core functionality relatively well, which I’m doubtful of.
Although the only official conversion out of the box will be for strings — because that’s all Txp has ever had — the core multiple-custom-fields implementation supports more field types than said quasi-supported plugin. And its table structure, efficiency, and storage space will be more optimised.
I haven’t looked at the roadblock (heh) but I guessing the custom fields extension work isn’t slated for 4.6. Yes?
Correct. 4.7 minimum. The biggest chore will be merging the current admin-side revamp into the custom field branch as they deviate massively. Waiting for a rainy day to do that. Then work can forge ahead on that feature.
Another option is to give contributors Txp accounts
Yes, but a Txp article can only have one “owner” (author) so you’re scuppered out of the gate if your goal is true co-authorship. Nothing to stop you assigning a list of authors in a custom field using a glz_cf script to grab the authors and present them as a multi-select list. Then the “author” of the document (first person to save the article) becomes irrelevant and you can just present the list of authors stored in the CF to the world.
As long as all authors are in a suitable group — which smd_um can help with — and have the ability edit one another’s articles, they can all jump in and tweak as they see fit. If anyone makes edits while someone else is doing so, a warning pops up when you try to save. You have to then choose to either hit Save again (obliterating the other person’s changes) or open the modified article in a new tab and compare it, then merge the changes into your version by hand. Not great, but as the edits aren’t shown “live” like they on Google Docs, for example, this is the best we have.
Incidentally, smd_um might help here a little bit, as it shows who’s logged in (though it only displays that on the Users panel, this could be extended to site-wide if necessary). At least that gives you a chance to decide not to edit a document if a co-author is logged in. I believe TheEric was once working on an admin-side chat tool for logged-in users. It was ransomware but he drifted away before it was finished. Or maybe even started, I dunno. There might be a copy of the code floating around somewhere if that would be helpful to fold into the site.
The other fields that are directly linked to the user account can be handled by smd_bio, as you suggest. And outputting things using RDFa is no sweat using Forms.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Multiple authors, single article
Thanks, Stef. As the situation stands, I don’t think there’s any viable solution, based on the fact:
- the irregularity of possible contributors to a given article (this is a glossary project where any number of different combinations of contributors at this point could be working on one or more of the 77+ definition articles in the glossary), and
- all of the draft collaboration actually takes place in Google docs. Txp is only used as the vessel to publish the production version, nothing more.
If the extended custom fields was in operation now, I’d simply define a textarea block for “contributors” and dump the manually-edited contributors/affiliations <section> into that. It’s only because that component of the article (everything in <section id="collaborators">) has such a high markup:content ratio that I don’t want to put it into the body field itself right now. (Hmm… or maybe.)
So until the core custom fields arrives (the one Txp uplift I’m looking forward to most), I think we’ll have to forego structuring the contributors as initially hoped. Instead of unordered lists with all the semantic chaining folded in, it’s just going to be an unstructured, comma-separated string of names as a paragraph in the body.
When the cf deliverance lands, Operation Glossary Upgrade will execute.
Offline
Offline
Re: Multiple authors, single article
Destry
Like Nicolas I wondered about smd_tags.
I also wondered if an approach like aam_split_custom_fields or Netcaver’s Packed Custom Fields might work for you?
Offline
Re: Multiple authors, single article
There is also <txp:authors /> tag in 4.6:
<txp:authors name='<txp:custom_field name="authors" />'>
<txp:author /> <!-- add some markup -->
</txp:authors>Offline
Pages: 1