Content forwarding

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
j. ayen green's picture
Posted by j. ayen green on August 2, 2015 at 7:31pm

The typical content creation process in for a Drupal site is to have the content creators do so on the production system, because databases are copied down, not up.

I'm working on a module that will be used, as an example, to allow the content creators to work on a staging server, and upon performing any CRUD on content, a transaction will be sent (REST for starters) to the production server, having it perform the same operation.

This is, in part, a response to clients who want to be able to create content on an internal server completely visible to all within the firewall (WITHOUT needing to login, so NOT dependent on publishing status), and when approved, have the content automatically moved to production.

Comments

There are a number of modules

Posted by David_Rothstein on August 3, 2015 at 3:40pm
David_Rothstein's picture

There are a number of modules in this space already that are worth taking a look at if you haven't already:

  • I'm guessing you may already be familiar with the Deploy module, which handles most of the backend for this.
  • A while ago I wrote the Shared Content module, which makes the above work in a user-friendly way with content creation. Hasn't been updated in a while, but it worked pretty nicely with older versions of Deploy and related modules (the demo still works and is a good way to do a quick test of this, although you wouldn't want to use the demo for anything but testing since it's bundled with an old and insecure version of Drupal core).
  • There is also the Services Client module, although I'm not too familiar with it myself.

Thanks for the reply. Well,

Posted by j. ayen green on August 3, 2015 at 9:01pm
j. ayen green's picture

Thanks for the reply. Well, the Services module could work, depending on being able to make the trigger a workflow event, but it says 'under heavy development' and hasn't been touched in over a year.

Your module also seems to be close to what is needed, if there is some relationship maintained between the source and destination nodes (not a nid, but a uuid or custom unique id) so that CRUD events can be transmitted and might need a tweaking of the supported workflow. Yours, however, depends on Deploy, and it seems to be undergoing a complete revamping.

Mine approaches it a bit differently. Content CRUD is captured in an intelligent FIFO queue (intelligent in that an update for a node not yet processed as an add removes the add from the queue, or a delete removes an add or update from the queue, etc.), and the queue is processed with thresholds during a cron run much like a mailing list would be.

UUIDs

Posted by David_Rothstein on August 6, 2015 at 4:35pm
David_Rothstein's picture

Your module also seems to be close to what is needed, if there is some relationship maintained between the source and destination nodes (not a nid, but a uuid or custom unique id) so that CRUD events can be transmitted

Yup, it uses UUIDs to track the relationship. (Anything based on Deploy will use UUIDs for this, I think, since the Deploy module depends on the UUID module and relies pretty heavily on it under the hood.)

Deploy works great

Posted by blainelang on August 6, 2015 at 6:45pm
blainelang's picture

I used the deploy module on a recent project to push content from a central content library site out to multiples (10's or 100's) of sites and it worked well.