Dynamic Description & Notes

[adrian]

I have been using this module for a long time and it's been incredibly useful so I thought it was time to share.

It's great for fields where you want to instruct content creators to reference something about a the page, its template, or its parent, or grand parent, etc

Specify fields/properties of the page in your field's Description or Notes content, eg:
[page.parent.url]
[page.title]
[page.template.label]

You can also define a str_replace to be performed on the returned value, eg: [page.name.(-|_)]
which will return the page name with the dashes replaced with underscores.

An option to allow raw HTML is available.

You can also use hanna codes within your description and notes fields - big thanks to @Robin S for this idea.

http://modules.processwire.com/modules/dynamic-description-notes/

https://github.com/adrianbj/DynamicDescriptionNotes/

Hope you find it useful.

[adrian]

Another possible use of this is pointing the user to edit another related page by making use of the ID of the related page, eg:

Test link to [Edit Parent](./?id=[page.parent.id])

which looks something like this:

Anyway, there are lots of possibilities for enhancing the content of your Description and Notes text.

[szabesz]

Thanks for sharing Adrian!

Is it possible to display values from an other language than the default? I would like to inject [page.url] and its counterparts from the other languages into the Title description of a blog page (just what we see in red on the Settings tab, but) it could be a good overview to see something like:

• /blog/my-nice-article/
• /es/blog/mi-buen-articulo/

I'm willing to hardcode the language IDs into it... 

Another question: what about "custom" php? Or is it out of the scope of the module, because if it is "custom", why not implement it from scratch in the first place?  

[adrian]

1 minute ago, szabesz said:

Thanks for sharing Adrian!

Is it possible to display values from an other language than the default? I would like to inject [page.url] and its counterparts from the other languages into the Title description of a blog page (just what we see in red on the Settings tab, but) it could be a good overview to see something like:

• /blog/my-nice-article/
• /es/blog/mi-buen-articulo/

I'm willing to hardcode the language IDs into it... 

Another question: what about "custom" php? Or is it out of the scope of the module, because if it is "custom", why not implement it from scratch in the first place?  

I knew I shouldn't have shared this module

Let me have a think about these and see what the best options might be.

 

[szabesz]

I'm sorry  

Anyway, do not spend too much time on it...

[adrian]

@szabesz - I just did a little thinking about this.

I know this isn't what you want, but I wanted to clarify that the module does already correctly display field values in the language of the user.

Unfortunately I don't really think it's feasible for this module to handle outputting multiple versions of something in different languages. Same goes for custom PHP - that would go against Ryan's desire for the description and note fields to be Markdown driven. 

I actually think you should be able to achieve what you are looking for using @kongondo's awesome RuntimeMarkup module. I use it in a lot of situations where I need more complex info for guiding clients. I know it doesn't output directly in the title description like you wanted, but you could place this directly below and it would almost be the same.

Hope that sounds reasonable to you.

[szabesz]

Thanks Adrian! It was just an idea I wanted to share but not really a feature request or so. And also thanks for reminding me of the RuntimeMarkup module!

[Robin S]

On 6/10/2016 at 4:28 AM, szabesz said:

Another question: what about "custom" php? Or is it out of the scope of the module, because if it is "custom", why not implement it from scratch in the first place?  

@szabesz - I had a play around to see how you could use custom PHP replacements in the description field. My first thought was create a module where you define tag/code pairs in the module config, then look for and replace those in descriptions. This works, but requires the use of eval() and conventional wisdom is that eval() is evil.

So my next thought was Hanna Code, and this seems to work great.

In ready.php (or create an autoload module):

$this->addHookBefore('Inputfield::render', function($event) {
    if(!$this->wire('modules')->isInstalled('TextformatterHannaCode')) return;
    if(!($this->wire('process') && $this->wire('process')->className() == 'ProcessPageEdit')) return;
    $inputfield = $event->object;
    $description = $inputfield->description;
    if($description == '') return;
    $this->wire('modules')->TextformatterHannaCode->formatValue(new Page(), new Field(), $description);
    $inputfield->description = $description;
});

Then set up the Hanna codes you want to use in description fields. If you want to get the page object for the page being edited then add this at the top of your Hanna code...

if($process && $process->className() == 'ProcessPageEdit') {
    $p = $process->getPage();
} else {
    return "[Hanna code '$hanna->name' is not valid for this field]";
}
return $p->url; // an example to return the URL to the page without scheme and hostname

...then access the page object as $p

Edited October 13, 2016 by Robin S
Minor code changes

[adrian]

Nice @Robin S - I really ilke the Hanna Code approach - ultimate flexibility and so simple to implement!

 

 

[tpr]

I have something like this in mind:

[object_name separator selector separator property]

eg.

[pages::template=news,title*=rock::title]

If its an array, use the first item. Wouldn't this be more flexible?

[szabesz]

Thanks a lot @Robin S! Last night I went to bed and had a great sleep, and this morning when I wake up, reading your post I realize that my dreams came true

I will have time to try it out in the evening, but looks rather straighforward. I agree with @adrian, it is really smart to use Hanna Code. I hope that this thingy here is not an issue anymore and just left open for some reason and even if it is still an issue, your way of using Hanna Code is not affected by this.

 

[szabesz]

@Robin S I have just find the time to try out your approch and since I like the Hanna Code module I will use it for sure.

On 10/7/2016 at 1:53 AM, Robin S said:

In ready.php (or create an autoload module):

I recommend updating your post at least with:

if(!$this->wire('modules')->isInstalled("TextformatterHannaCode")) return;

Just to make sure we never run into a fatal error.

Also for the sake of completeness, an example might be good to add in the Hanna Code itself:

return $p->url; // an example to return the URL to the page without scheme and hostname

Or something similar  

It would also be nice to add this to http://processwire-recipes.com/ but contribution to the PW Recipes sounds convoluted to me, so probably that is why it is not so popular among forum contributors. It's a pity though...

[Robin S]

On 9/10/2016 at 5:11 AM, szabesz said:

I recommend updating your post

@szabesz: I updated the code examples.

[adrian]

Hi everyone,

I have just updated this module to support insertion of Hanna codes, and renamed it to DynamicDescriptionNotes.

It passes the $page (for the current page being edited) and $field (for the $field where the Description or Notes text is referencing the Hanna code, so you can use $page and $hanna->field in your Hanna code to refer to these. This opens up lots of possibilities for dynamic content.

Please let me know if you have any problems or suggestions.

A big thank to @Robin S for the awesome idea!

PS, It's now available from the modules directory: http://modules.processwire.com/modules/dynamic-description-notes/

[szabesz]

Awesome, thanks Adrian!

[xportde]

Hi Adrian, we've been using this very useful module intensively to comment fields for our customers, especially by the "allow-HTML"-option. Unfortunately, the support of HTML tags seems to be broken in version 0.1.0. Could you check this out, please?

[adrian]

5 hours ago, xportde said:

Hi Adrian, we've been using this very useful module intensively to comment fields for our customers, especially by the "allow-HTML"-option. Unfortunately, the support of HTML tags seems to be broken in version 0.1.0. Could you check this out, please?

Glad you've found it so useful.

Sorry for the bug in that version. I have just committed a fix.

Please let me know if you have any other problems.

[xportde]

Thank you, Adrian!

[xportde]

Hi Adrian,

since 0.1.4, the support of HTML tags seems to be broken in fields of combined field types, e.g. FieldsetPage or Textareas. Could you check this out, please?

Thanks in advance,

Thomas.

[adrian]

Hi @xportde - sorry about that. I have reverted those changes and taken a different approach to what I was trying to fix. FieldsetPage fields now work as expected, but there is still a problem with the individual fields under a textareas field, but I don't think that is related to the version of this module - I just don't think the Textareas module supports setting "entityEncodeText" to false, which is how this module allows html in the description. If I am correct in this assumption, then it is something Ryan will need to fix. Let me know your thoughts.

[xportde]

Thank you, Adrian, now everything works as expected, also in fields of type TextAreas!

[LAPS]

Hi @adrian,
maybe I've a problem some way related to the one of @xportde.

I just installed DynamicDescriptionNotes 0.1.6 in ProcessWire 3.0.200.

In DDN module settings I tried both options: "Allow HTML" checked and unchecked.

If "Allow HTML" is unchecked then Markdown is "translated to HTML" but output is raw HTML.

If "Allow HTML" is checked then Markdown output is raw.

I set "Notes" and "Description" (field settings in template context) as follows:

Some **Markdown** text `code` [link](/path/to/a/page/).
- [page.parent.url]
- [page.title]
- Test link to [Edit Parent](./?id=[page.parent.id])

 

What could be the problem?

[adrian]

Thanks for the report @LAPS - it should be fixed in the latest version. Please let me know.

[teppo]

Hey @adrian!

Might be a strange use case (considering that it doesn't seem to be supported yet), but I'd like to use this module for a field that's locked (non-editable). Looks like hooking into Inputfield::render won't work in this case, while Inputfield::renderReadyHook does work. To be honest I'm not sure what else that might change/break ?

I've made that change locally since this is indeed something I need, and so far it seems to work (though not much testing done yet).

Also... have you considered updating the module to PW3? I mean adding the namespace, mainly, so that module compile wouldn't be needed. And it would be great to have this module installable via Composer. Food for thought ??

[teppo]

One more thing: I'm wondering if there's some use case where current way of getting properties via eval is necessary?

I don't see anything technically wrong with that, but would feel better not using eval at all, and it tends to get flagged by security audits etc. This seems to achieve largely similar results, at least in latest PW version:

$replacement = $p->get(implode('.', $properties));

Again my use case for this module is very limited for now, so may be missing something important.