HannaCodeDialog

[schwarzdesign]

Thanks for the follow-up @Robin S. The toolbar settings are correct – the same field is displaying the toolbar item fine when it's not inside the RepeaterMatrix field.

Which version of RepeaterMatrix have you tested this with? I'm using the current v5-dev Version. I just switched to RepeaterMatrix v4 as a test, with this version it's working correctly. Can you check if you're getting the same problem in the v5-dev version? Thanks!

[Robin S]

22 minutes ago, schwarzdesign said:

Which version of RepeaterMatrix have you tested this with?

I'm using the very latest v5d dev version, shared by Ryan here: https://processwire.com/talk/topic/21581-repeater-matrix-v5/?do=findComment&comment=199110

But Ryan addressed that version to you so maybe you are already using it? If you're not try updating to it because this topic makes me think there might have been a problem with CKEditor fields and Repeater Matrix: https://processwire.com/talk/topic/22029-ckeditor-field-context-per-matrix-type/

 

 

[schwarzdesign]

@Robin S Yes, that's the version I'm using. Hm, curious. Though that's not the first issue I have with CK Editor fields inside RepeaterMatrix fields (see the thread you linked above as an example). I'm wondering if there's something wrong with my ProcessWire installation or something. I'll investigate further next week!

[MarkE]

Regarding attributes of type pagelistselect, it would be really useful to be able to specify the parent page to restrict the selection. I assume it may be possible to do this in a hook somehow, but might it also be a useful enhancement - something like attribute__parent=id?

[Robin S]

2 hours ago, MarkE said:

Regarding attributes of type pagelistselect, it would be really useful to be able to specify the parent page to restrict the selection.

You'll need to use a HannaCodeDialog::buildForm hook for that - there are way too many potential form and inputfield options to support with dedicated syntax in this module. See this section of the readme for an example hook: https://github.com/Toutouwai/HannaCodeDialog#build-entire-dialog-form-in-a-hook

The PageListSelect property you want to set is parent_id. Sing out if you get stuck. 

[MarkE]

Here's what I did:

$wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) {

    // The Hanna tag that is being opened in the dialog
    $tag_name = $event->arguments(0);

    // The form rendered in the dialog
    /* @var InputfieldForm $form */
    $form = $event->return;

    if($tag_name === 'BusinessProcess') {
        $modules = $event->wire('modules');
        // Generate page list
        $f = $modules->InputfieldPageListSelect;
        $f->set('parent_id', 6199);
        $f->name = 'businessProcess';
        $f->id = 'businessProcess';
        $f->label = 'businessProcess';
        $form->add($f);
    }
});

 

[schwarzdesign]

On 4/30/2020 at 4:47 PM, schwarzdesign said:

@Robin S Yes, that's the version I'm using. Hm, curious. Though that's not the first issue I have with CK Editor fields inside RepeaterMatrix fields (see the thread you linked above as an example). I'm wondering if there's something wrong with my ProcessWire installation or something. I'll investigate further next week!

Hi @Robin S, I have tested a couple more scenarios, I believe the missing dropdown has something to do with the dynamic AJAX-loading of repeater matrix items. If I set "Repeater dynamic loading (AJAX) in editor" to "New items only", the Hanna Dialog appears on all existing repeater items. Though if I then add a new repeater matrix item of a type that's not used on this page yet, the Hanna Dialog is missing. Once I save the page and the new item is loaded through the normal page visit, the Hanna Dialog shows up. So probably the hook that adds the JS settings just doesn't fire for AJAX-loaded items?

To test this, I've put a bd($key) statement on this line where the extraPlugins config is added. When dynamic loading for my repeater field is set to "New items only", it shows all CK Editor fields, even those inside the repeater matrix:

But if I activate AJAX-loading for all repeater items, the matrix CK Editor inputfields don't show up:

---

So, disabling AJAX mostly fixes the problem, though the dialog is missing form newly added repeater matrix items before the page is saved. Do you think it's possible to make this work with AJAX-loaded repeater matrix items as well?

Thanks for your help!

---

EDIT: Another thing I found: It's working fine when I disable all local field overrides for the CK Editor field (it's set to required in the Repeater Matrix context). So probably if there are no overrides the Matrix just uses the config of the normal "InputfieldCKEditor_html_basic", which includes the HannaDialog, but if there ARE overrides it generates the "InputfieldCKEditor_html_basic_matrix1" configs which DON'T include the HannaDialog plugin because they're loaded through AJAX. Does that make sense?

[Robin S]

On 5/8/2020 at 9:41 PM, schwarzdesign said:

It's working fine when I disable all local field overrides for the CK Editor field

Thanks for reporting and testing - v0.3.2 has a fix for when CKEditor fields have settings overrides per Repeater Matrix type.

[schwarzdesign]

Thanks for your help @Robin S!

[schwarzdesign]

Hi @Robin S, how do you feel about adding integer fields to the dialog? I have some fields that would benefit from allowing numbers only. I have tested adding the InputfieldInteger with inputType 'number' (for HTML5 support) and it works well:

// iframe_form.php
$type = 'InputfieldText';
if(isset($types[$key])) {
    switch($types[$key]) {
		/** ... */
        case 'integer':
			$type = 'InputfieldInteger';
          	break;
	}
}
$f = $this->modules->get($type);
if ($type == 'InputfieldInteger') {
	$f->inputType = 'number';
}

Would you consider adding something like this to the module?

[Robin S]

13 hours ago, schwarzdesign said:

how do you feel about adding integer fields to the dialog?

I've added support for an "integer" inputfield type in v0.3.3. Technically it was already supported via a HannaCodeDialog::buildForm hook which is the approach I would generally recommend to power users. Once you start going beyond the basics I think it's easier and more powerful to build your dialog forms via that hook.

[schwarzdesign]

@Robin S Alright I'll try this, thanks!

[Ivan Gretsky]

Good day, @Robin S!

I've just read through the whole forum thread and found out a lot of great things about this module. It is great and way more powerful than I could imagine!

But the issue I was hoping to resolve wasn't there. I am trying to use the module in a frontend-edit context, but it doesn't seem to work. The Insert Hanna Code button isn't even in the toolbox. What am I doing wrong? Can I make it work here?

[Robin S]

2 hours ago, Ivan Gretsky said:

Can I make it work here?

Only if you use Option D for front-end editing in a dialog. Hanna Code Dialog works by hooking ProcessPageEdit::execute and this method isn't called when using inline front-end editing. PageFrontEdit doesn't even have any hookable methods so there's really no scope for the kind of customisation done by Hanna Code Dialog.

[Ivan Gretsky]

6 minutes ago, Robin S said:

Only if you use Option D for front-end editing in a dialog. Hanna Code Dialog works by hooking ProcessPageEdit::execute and this method isn't called when using inline front-end editing. PageFrontEdit doesn't even have any hookable methods so there's really no scope for the kind of customisation done by Hanna Code Dialog.

Thanks! But that is obviously not the case for me)

Do you think we should try to change the situation by asking Ryan to add similar hookable methods to PageFrontEdit? Or does it seem impossible to implement anyway?

[Robin S]

5 hours ago, Ivan Gretsky said:

Or does it seem impossible to implement anyway?

I couldn't confidently say "impossible" but the front-end is a totally different context to the back-end so it would require substantial changes to the module, and I expect there would need to be changes to PageFrontEdit to allow modules to inject CSS and JS into the frontend.

I'm not that motivated to spend a lot of time on it because I never use front-end editing and if I did and needed Hanna Code Dialog I would just use Option D because in my opinion it's no great loss to switch to a modal editor for such cases. So sorry to disappoint but the response for now is "if you need Hanna Code Dialog on the front-end bad enough then use Option D". Of course the module is open-source so you are welcome to experiment with it and modify it as needed.

[adrian]

@Robin S - not sure if this is a new issue (maybe a change to the PW core - I am running latest dev version), but it looks like the dropdown is not showing when the field is in a repeater. I haven't looked at this field in a while, but I am pretty sure it used to work. Let me know if you can't reproduce and I'll look into it more. Thanks.

[Robin S]

1 hour ago, adrian said:

it looks like the dropdown is not showing when the field is in a repeater

I tested with the latest dev and latest version of the module but I can't reproduce that. The dropdown appears for CKEditor fields where it is added to the toolbar, inside a repeater or nested repeater. Let me know if you can give me any more tips for how to reproduce, thanks.

[adrian]

@Robin S - sorry, turns out it wasn't a repeater issue, but rather because I didn't have the Hanna Code Text Formatter applied to the textarea field. The thing is that I don't actually want it applied because I handle the replacements myself with my own template code rather than code within the Hanna rule. This doesn't prevent me from applying the text formatter to the field anyway, but what does prevent me from wanting to do that is that I use the text as the label for the repeater item and I want the hanna code to show in that label, eg, I don't want this:

but rather this:

Do you think you could alter things so that the text formatter doesn't need to be applied to the field?

[Robin S]

22 minutes ago, adrian said:

Do you think you could alter things so that the text formatter doesn't need to be applied to the field?

I'm reluctant to do that because the presence of the Hanna Code textformatter is how the module knows whether it should be interfering with the CKEditor field by loading plugins that will widgetise strings surrounded by the Hanna Code delimiters. Although it wouldn't be a common scenario, it ought to be possible for someone to use the Hanna Code delimiters for some other purpose within a field that isn't configured for Hanna Code without Hanna Code Dialog messing with it.

You situation sounds like a fringe case. If the objective is to use unformatted field content in the repeater label could you use a hook instead? E.g.

$wire->addHookAfter('InputfieldRepeater::renderRepeaterLabel', function (HookEvent $event) {
	$page = $event->arguments(2);
	$inputfield = $event->object;
	$field = $inputfield->hasField;
	if($field->name !== 'your_repeater') return;
	$label = strip_tags($event->wire()->sanitizer->truncate($page->getUnformatted('body'), ['maxLength' => 100, 'more' => '']));
	$event->return = $label;
});

 

[adrian]

Thanks Robin - I guess I thought that if you applied the "HannaDropdown" option to the CkEditor settings, that would be indicative enough that you wanted to process that field and widgetise the strings, but I do understand your second point. The hook you provided is a good solution, although now that I have applied the hanna code text formatter, I do need to also use getUnformatted() on the body field when outputting content on the site so that it isn't processed by Hanna. I think it would be nice if PW had a dedicated way to remove a specific textformatter when outputting so that others are still applied - I don't think that is possible though.

[Robin S]

16 minutes ago, adrian said:

The hook you provided is a good solution, although now that I have applied the hanna code text formatter, I do need to also use getUnformatted() on the body field when outputting content on the site so that it isn't processed by Hanna. I think it would be nice if PW had a dedicated way to remove a specific textformatter when outputting so that others are still applied - I don't think that is possible though.

I can see why that isn't optimal and I agree that it would be good to be able to selectively disable particular textformatters when outputting.

The Hanna Code Dialog module depends on Hanna Code and isn't intended to be used independently of it. The way you're using it is unusual so although I don't want to make changes to the module that I think could compromise the experience for typical users you could use a custom hook/module that would load the Hanna Code Dialog CKE plugins to suit your circumstances. So you'd create your own custom version of HannaCodeDialog::afterCkeRenderReady().

$wire->addHookAfter('InputfieldCKEditor::renderReadyHook', function (HookEvent $event) {
	$inputfield = $event->object;
	$field = $inputfield->hasField;
	// For your field name(s)...
	if(!$field || $field->name !== 'body') return;
	$config_name = "InputfieldCKEditor_{$field->name}";
	$config_name_matrix = "InputfieldCKEditor_{$field->name}_matrix";
	$config = $this->wire('config');
	$js_config = $config->js();
	foreach($js_config as $key => $value) {
		if($key === $config_name || strpos($key, $config_name_matrix) === 0) {
			$js_config[$key]['extraPlugins'] .= ',hannadropdown,hannadialog';
			$config->js($key, $js_config[$key]);
		}
	}
});

 

[adrian]

Jeez, you're a bloody legend ?

This feels much nicer!

You really went the extra mile with supporting this request - much appreciated.

Thanks again.

 

[MarkE]

This is one of my favourite modules and I use it a lot to provide user-customisation of, for example, email contents. In particular, I have managed to reduce the number of hanna codes used by introducing dialogs with page-select attributes (limited to certain children, specified by a hook described earlier in this thread). This works really well and avoids the need for head-scratching over tag names, but has one slight disadvantage in that the selected page is shown as an id in the text area - e.g. [[RentalPayment payment_type="5363" net_gross="Net" due="" format="£0.00" absolute=""]]. Unless the user can remember what page id 5363 is, they have to click the code to display it in the dialog. That's no great hardship, but in a text area filled with several such codes, it would be nice to display the name rather than the id.

I'm wondering if there is a way to achieve a more meaningful display in the text area. I guess I could introduce a text or select attribute (unused in the code) which the user could use to document the selection. That seems a bit unreliable, however. It would be nice to fill the dummy attribute automatically, so my next idea was to use a hook - which is where I started running out of ideas: the hook would need to be on the page selection and somehow rebuild the form, whch all start to feel a bit messy.

Any better ideas?

[Robin S]

11 hours ago, MarkE said:

but has one slight disadvantage in that the selected page is shown as an id in the text area

The core Page Reference inputfields output only a page ID and expect a page ID as input.

Possibly you could create your own custom inputfield module that works with a page path instead of an ID.

Or here's a hacky solution that involves adding an extra "path" attribute to your Hanna tag...

Hook:

$wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) {

	// The Hanna tag that is being opened in the dialog
	$tag_name = $event->arguments(0);

	// The form rendered in the dialog
	/* @var InputfieldForm $form */
	$form = $event->return;

	$config = $event->wire()->config;
	$modules = $event->wire()->modules;

	if($tag_name === 'select_page') {
		/* @var InputfieldPageListSelect $f */
		$f = $modules->InputfieldPageListSelect;
		$f->name = 'selected_page';
		$f->id = 'selected_page';
		$f->label = 'Selected page';
		$f->parent_id = 1268;
		$form->add($f);

		// Add JS file to Hanna Code Dialog form
		$js_file = $config->paths->templates . 'hannas/select_page.js';
		if(is_file($js_file)) {
			$js_url = $config->urls->templates . 'hannas/select_page.js?v=' . filemtime($js_file);
			$form->appendMarkup = "<script src='$js_url'></script>";
		}
	}

});

select_page.js

$(document).ready(function() {

	// Must use mousedown instead of click event due to frustrating event propagation issues across PW core
	// https://github.com/processwire/processwire-issues/issues/1028
	$(document).on('mousedown', '.PageListActionSelect a', function(event) {
		var path;
		// Adapt unselect label to suit your language
		if($(this).text() === 'Unselect') {
			path = '';
		} else {
			path = $(this).closest('.PageListItem').children('.PageListPage').attr('title');
		}
		// Adapt path field ID to suit
		$('#path').val(path);
	});
	
});