Use simplytest.me as demo plattform

This patch adds tmgmt_demo module. It sets up all necessary elements for a demo site.

By simply activating the 'Translation Management Core' module, all other needed modules are activated and settings and contents added.

Not yet tested with simplytest.me, as the patch is not yet up on d.o (it will be in a few minutes)

here ist the patch....

It does work on simplytest.me :-)

The url is: http://simplytest.me/project/tmgmt/7.x-1.x?patch[]=https://drupal.org/fi...

It takes a while to launch...

Great to see progress here! Some first review.

1. +++ b/tmgmt.info
   @@ -6,6 +6,7 @@ core = 7.x
   +dependencies[] = tmgmt_demo
   

   I don't think this dependency direction was the idea.

2. +++ b/tmgmt_demo.info
   @@ -0,0 +1,9 @@
   +name = Translation Management Demo
   

   Not hidden yet as suggested.

3. +++ b/tmgmt_demo.module
   @@ -0,0 +1,71 @@
   +function tmgmt_demo_modules_installed($modules) {
   ...
   +    node_save($node);
   

   This is executed for every module enable completion. Later module enables might result in content duplicates added. May be add an early exit against multiple runs.

4. +++ b/tmgmt_demo.module
   @@ -0,0 +1,71 @@
   +    // Set up MS Translator.
   ...
   +      $translator->settings['clientsecret'] = 'iur…';
   +      $translator->settings['clientid'] = 'bca…';
   

   MS? ;-) I see, this seems comfortable. But i guess it's against M$ license agreements to publish private keys.

   Also missing install of the local translator.

5. +++ b/tmgmt_demo.module
   @@ -0,0 +1,71 @@
   +    $node = new stdClass();
   +    $node->title = 'Second node';
   

   How about using devel_generate? Not sure. But i guess we need more example cases.

1) This is the only way to trigger the installation and activation of tmgmt_demo on Simplytest.me. If we want a ready-to-use demo system there, we need to make the patch self starting.

2) There is no need to ever load this module onto d.o. So no manual installation/activation is possible. Hiding is still an option, but no requirement.

3) This only gets triggered after installing 'locale'. How could it be executed multiple times?

4) Including Local Translator as a dependency breaks the installation, resulting in multiple notices. I do not understand why....(any suggestions?) Also, LT requires much more guidance for the casual demo user to understand.

5) Somebody told me the other day that users need real text to relate to the system.....

In re...

> 1) This is the only way to trigger the installation and activation of tmgmt_demo on Simplytest.me. If we want a ready-to-use demo system there, we need to make the patch self starting.
Thought you can pass to them to enable tmgmt_demo on install. See link.

> 2) There is no need to ever load this module onto d.o. So no manual installation/activation is possible. Hiding is still an option, but no requirement.
This module also should never be enabled in production, so we don't it to show up in module list.

> 3) This only gets triggered after installing 'locale'. How could it be executed multiple times?
It's hook_module_installed. It gets executed after each module install: https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...
If you want to limit it to locale, i would suggest an early exit.

if !(in_array('locale', $modules)) {
  return
}

> 4) Including Local Translator as a dependency breaks the installation, resulting in multiple notices. I do not understand why....(any suggestions?) Also, LT requires much more guidance for the casual demo user to understand.
I see, there are multiple approaches: testing only a simple/reduced setup VS testing extended features / anything possible. With DSB we name this "scenarios" and have different cases to address. With this approach we either would need multiple submodules for each scenario or even choose the install profile approach.

> 5) Somebody told me the other day that users need real text to relate to the system.....
Fully agree that gibberish adds complexity. Is there anything like wikipedia generate? (or should we use wget? is wget even allowed in simplytest.me?!) ;-)

3) Using hook_install in tmgmt_demo not only results in notices but completely crashes the system (resulting in everything but tmgmt core enabled...). Will try the path of module_enable combined with hook_install

Please use one of the following .info directives to enable a module on simplytest.me programatically:

recommends[] = some_module
test_dependencies[] = some_module
simplytest_dependencies[] = some_module

I updated the documentation page according to that info.

You can find this and more at the Questions and Answers section of simplytest.me: http://simplytest.me/qa#developers

I just re-read my own documentation and realized that these directives only fetch the specified dependencies and don't install them. (stupid me, sorry!)

But that's (obviously) not very intuitive: change request here: #2116901: Not only fetch, but also enable recommended / demo dependencies

Initial patch to test simplytest_dependencies[]

Demo module is not yet hidden, so we can turn it on manually on testing site.
Core and Demo must be turned on one at a time.

In simplytest.me, demo should be enabled by the sandbox.

Did not work.

An error occurred while patching the project. says simplytest.me

Any idea?

sidenote cgalli: with drush you can also enable hidden modules.

The same thing happens in manual install. When enabling/installing Core and Demo at the same time, the hook_install does not seem to be invoked. When enabling them in sequence (Enable core, save, enable demo save), it works.

Great work, guys. Works for me as a very basic setup.

However, note that in #2 cgalli already did more like create some basic nodes that reduce clicking to create a first job.
Also translators are no more setup.

Will we need some helper node / block that explains the required/recommended steps?

(all followup?)

I will take care of that.

- Adapted demo to use the local translator and xliff only.
- Added the demo content back, could not find a reasonable source for dummy content.
- The uninstall hook does not run through, I do not understand why. Please advise.
- The module is not hidden yet for testing purposes.

debugging broken test

Problem is in the order of jobs. The test expects the tested job to be in the second position in the list, which is not always true during tests. Rewrote the xpath to search for the expected text and not to rely on the order.

Changed user_save(), the Login works again.

Add: The patch works correctly with simplytest.me :-)

Adjusted Documentation.

The attached patch fixes a little mistake preventing reinstallation. In addition it adds 2 specific links to the documentation.

If anybody knows how to make those 2 links open in a new tab ('TARGET = _BLANK'), please advise. It is not optimal to start a simplytest.me session just to replace it with the documentation page immediately).

Modifying the target of the link is no core feature. It requires some ugly code... .-)

The documentation links are public. I would not check for "access content" permission. Instead always deliver: TRUE.

I guess long term i would create a separate menu "Documentation" and place it in the design. Thus also remove the "Documentation for" chunks from the link title.
Also in this case it is more easy to add the target for all documentation links in the documentation menu.

Problem: You added a bugfix and a new feature into the same issue. The basic feature of simplytest.me went in with TMGMT. We usually continue in followup issues and separate the different aspects (one bug, one feature).

Follow up Issue: #2142557: Demo Module cannot be (re)installed for the bug fix