Setup basis Context Help Display

[p-a-s-c-a-l]

Provides facilities to show content in popup (Lightbox, ...) with help messages.

[fgeyer16]

Patrick please create a module help_widgets (best using drupal console). The widgets classes have to be located in the forlder src/Plugin/Field/FieldWidget. For the beginning we will make a widget for text fields and text area fields. The widget classes for them are located in
drupal_root/core/lib/ Drupal/Core/Plugin/Field/FieldWidget/

• StringTextareaWidget.php
• StringTextfieldWidget.php

We add two new fields to the widget one for the help text and one for the example.
A FieldWidget how to is https://www.drupal.org/docs/8/creating-custom-modules/create-a-custom-field-widget.
url-element for the settings form: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!Element!Url.php/class/Url/8.2.x
and the link element for the dispaly: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!Element!Link.php/class/Link/8.2.x

A list of render and Form elemnts in Drupal : https://api.drupal.org/api/drupal/elements/8.2.x
you will need the

[patrickkaleta]

@fgeyer16:
Regarding the Drupal console, I'm not sure how to call it inside the docker container. Executing "drupal" gives me a "command not found" message. I checked and the Drupal console is already included in the composer.json file, so how can I use it inside the docker container?

[fgeyer16]

@patrickkaleta
call from /app in docker "vendor/bin/drupal"

[patrickkaleta]

@fgeyer16
first version of the module is installed and enabled on the server. Currently the widget is working for the fields Text (plain) and Text (plain, long). The paths to the examples and help texts can be set via Manage Form display in the BE.

I didn't include any CSS (I guess we only need 2 icons and adjust their position in the form) since I'm not sure whether we should put this inside the module itself or more globally inside the theme. What would be the proper way, Florian?

Note: The entered paths are being validated before saving, so they have to already exist before being used in the form display.

[fgeyer16]

Maybe some basic styling could be done in the module.
So we have the links. The next step is to open them in a popover. I thought with the ng-lightbox module enabled and properly configured it should work without further work. But I tried it this way and it did not work.
@patrickkaleta
So can you investigate? So far I can see, the link is not modified for lightbox even if the path is entered in the Settings of ng_lightbox.
My conclusion is, that hook_link_alter is not called on links created by render element. Now we can

• create the links in a way that hook_link_alter works
• hardcode the markup for popovers into the widget.

Just for the widget I would do the later. For curiosity I would do the first :-)
Maybe give creating the link like here one fast try, and if it not works immediately hardcode the modal stuff.

[patrickkaleta]

@fgeyer16
just checked and ng_lightbox is working as expected. You probably overlooked that for the example page I manually changed the path to be "/help/test", so when you configured the lightbox to fire on "/node/1", it wasn't triggered. Sorry for that...

Now I see 2 possible options:

1. I can still hardcode the markup into the widget. I tried it and it's easily done and works well. Nothing else would be needed and the lightbox would appear for any paths seth in the contextual help widget and only there.

2. configure the lightbox module to be triggered only on specific paths like e.g. /contextual-help/[Node Title]
   a) this would require a special content type designated only for the contextual help, for which we would automatically set the path via the Pathauto module to match the configured path in the lightbox module
   b) theoretically, since the contextual help will be done by (probably) 1 or just a few people and the total amount of those elements should be manageable, we could use one of the other content types and set the path manually by hand (just like I did with the test example). So we wouldn't need an extra content type and no pathauto rule.

personally, I'm in favour of option 2a.

[fgeyer16]

Hm maybe I forgot to flush the cache.
I prefer option 2a. Having a dedicated content type makes permission and content management more clear.

[p-a-s-c-a-l]

/drupal-data/web/modules/custom/help_widgets is now excluded from docker-drupal repository (see also c995784) and is owned by user docker which does not have push access to help-widgets-module repository!

To update the module you have to su to docker and then issue a git pull. Editing the module code directly in /drupal-data/web/modules/custom/help_widgets is no longer possible.

[patrickkaleta]

I implemented option 2a.

I created a new content type called "Contextual help" with just a body field, where text and images can be added. Then I set up Pathauto to automatically create paths for this content type in the following manner: /help/[Node ID]

Those paths can then by used for the help-widgets module.

Right now the module is configured for plain textareas and textfields. If we don't need any additional fields for the moment, I guess that we could close this issue?

[DanielRodera]

Right now the module is configured for plain textareas and textfields. If we don't need any additional fields for the moment, I guess that we could close this issue?

Do you need anything for my side or as suggested @patrickkaleta, can we close this issue?