(Putting this here for future projects. No action required, but please @Matthias and @Nadia read)
We have been using the challenge response format for over a year now. It works quite well. But it has a problem: since challenge responses are not part of groups, they are harder to parse between those that belong to different projects. We use parsing to two ends:
- For using in Drupal APIs (through jsonview).
- For project-level web analytics
Parsing nodes for Drupal APIs
Server side, APIs rely on SQL queries like:
SELECT DISTINCT node.title […] WHERE (( (node.status = ‘1’) )AND( (og_membership.gid = ‘5954’)) )
If you don’t have the gid reference (= Group ID) you are in trouble. In OpenCare, we deal with this simply by including all nodes of type challenge response:
[…] WHERE (( (node.status = ‘1’) )AND( (og_membership.gid = ‘5954’) OR (node.type IN (‘challenge_response’)) ))
We can only do this once. For the second project, it will be unviable.
Parsing pages for web analytics
In OpenCare, I get asked a lot about visits to opencare pages. With the normal Drupal Commons model, I can do this by filtering pageviews by a regular expression on the URL, because Drupal “formats” URLS:
https://edgeryders.eu/groupname/pagename
Obviously challenge response do not have this. So, there is no easy way to know how many of ERs page views are attributable to project X.
Conclusion
Unless you have other solutions in mind, I would propose to return to a group-based data model. We can keep the whole mechanics and look-and-feel of Challenge responses, but assign them to a group. All the exisiting one are assigned to OpenCare with a SQL query.