Robin S

This one maybe?

Yeah, looks like the extra markup isn't appended when the modal GET variable is present. https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/modules/System/SystemNotifications/SystemNotifications.module#L113-L115

That's strange. I didn't test with real modals (just appended "modal=1" to the urls) but see the screenshots below of Page Edit and a module config. Maybe something is different when the page is really inside a modal.

Not sure I understand what you mean, but the native notices do appear regardless of whether an admin page is viewed in a modal (?modal=1) or not. Or do you mean you want to prevent the notices from appearing normally and open a modal window that only displays the notices?

You don't have to symlink anything - just keep the CKEditor plugin inside your module folder and then load that path as an external plugin.

I just private messaged you with some stuff, but for anyone else that is following the discussion, check out how Hanna Code Helper handles the loading of a CKEditor plugin: https://github.com/teppokoivula/HannaCodeHelper/blob/c26b3b7eeafa17dd8500dc1b89cbb88218ceca9c/HannaCodeHelper.module#L55-L97

Just tested this and it works for me - I can also see checked checkboxes contained inside InputfieldMarkup (but not unchecked ones). public function getModuleConfigInputfields() { $post = $this->input->post; bd($post, 'post'); $inputfields = new InputfieldWrapper(); $f_name = 'addnew_text'; $f = $this->modules->get('InputfieldText'); $f->name = $f_name; $f->label = 'A text field'; $f->value = $this->$f_name ?: 'Add New'; $inputfields->add($f); $f = $this->modules->get('InputfieldMarkup'); $f->name = 'my_markup'; $f->label = 'My markup'; $f->value = " <label> <input type='checkbox' name='my_checkbox'> My checkbox </label> "; $inputfields->add($f); return $inputfields; } This approach seems strange to me. Normally your module config is what defines your settings - so you check the module config values in your module methods and do things accordingly. You seem to be doing it back-to-front, like you are looking for settings defined elsewhere and then putting fields into your module config. Wouldn't it be better to just use actual checkbox fields in your module config to define the settings?

I think you want to have a method in your module that hooks Modules::saveModuleConfigData. At the top of that method you check if it is your module that was saved and return if not. $module_name = $event->arguments('className'); if(is_object($module_name)) $module_name = $module_name->className(); if($module_name !== $this->className()) return; Then do whatever based on the saved config data. $cfg = $event->arguments('configData'); I think you can also get submitted config values from $input->post within your getModuleConfigInputfields() method but that seems less desirable.

@ryan, could you please make a full profile of the updated Skyscrapers demo available? So it is easily installable for people to try out, like the previous version. It has come up a couple of times in the forums recently.

The Skyscrapers demo is a good example of a collection profile. http://processwire.com/demo/ https://github.com/ryancramerdesign/skyscrapers2 The demo was updated recently and I don't think a full profile of that is available yet. But the template files in the GitHub repo show how the site works. And the old Skyscrapers profile is available here if you're interested.

$page is an API variable, so it's already defined at the time your _init.php runs. $child is not an API variable - it's a variable that you have defined yourself. So you need to make sure it is defined before you try and do anything with it such as $child->created. I don't see $child being defined in your _init.php. I tried both the renderPager() examples you gave and they execute fine. There must be something else that is causing the 500 error. Check your error logs to see if that sheds any light. Are you developing locally or on a live server? If it's a live hosting you may be getting false positives from mod_security if that is installed, so ask your host to disable mod_security in that case.

@Elías Gómez, can you post the code you are using to loop over your event pages? It's hard to offer much advice without seeing that. Also let us know what you have selected for the "Formatted value" in the settings of your image field. As a general tip, if you spend a little time getting to know the Tracy Debugger module you will find it very valuable for investigating these kinds of issues. https://processwire.com/blog/posts/introducing-tracy-debugger/ http://modules.processwire.com/modules/tracy-debugger/

Nothing useful on the body I think but there is a class on the h1 and also its containing div:

I think maybe you are already onto this idea (saw your posts in another thread), but you could use RuntimeMarkup to create a non-editable table view in Page Edit showing the payments.

Hi NikNak. That's correct - think of the role dropdown as a required field. Come to think of it, I will set the that config inputfield as required in a module update. While it would be possible to restrict PageTables for superusers with this module, I deliberately excluded superusers from the role dropdown. My view is that it is part of the PW philosophy that the superuser role is not subject to any access restrictions and I want the module to be consistent with that. IMHO the only user that should have the superuser role is the site developer - you shouldn't give superuser access to a client. Better to create new role for the client with whatever access is needed.

Try ticking the "Make field value accessible from API even if not viewable" checkbox under "Access toggles".

See the pagination docs for how to change the markup/classes output by MarkupPagerNav: https://processwire.com/api/modules/markup-pager-nav/

You'll want to use $page->rootParent as the starting point of your menu. But for a simple menu like this (and even not-so-simple ones) I recommend trying MarkupSimpleNavigation as it covers all the common menu needs out-of-the-box.

I noticed that the position:relative rule that AOS adds to h1 makes the select dropdowns in the ProDevTools API Explorer unclickable.

Well, you should be a bit wary in that a person with edit access to the page could insert some malicious Javascript. If the person editing the website is the site owner then of course they would have no reason to do such a thing. As a general principle I think you should only make editable the parts of the code that it is essential to keep editable. For example, if your client only needs to change the "data-widget-id" attribute then make a text field just for that part and keep the rest of the snippet static in your template file. As an added benefit it also minimises the chances that they accidentally mess up the snippet code.

Thanks! Hope you feel better soon. I tried a few things but I don't have a good grasp of how the recommended way to set inline mode... session.setMode({path:"ace/mode/php", inline:true}) ...relates to the module's implementation of Ace. The only thing I could find relating to the PHP inline mode is in mode-php.js: ... "ace/mode/php-inline" ... So maybe this is an alternative way to set PHP inline mode? Hard to make sense of it with the source being minified.

Spotted a couple of things here. I think you want the last breadcrumb item outside of the foreach loop - otherwise when there are multiple parents you will get multiple copies of the 'active' item. And folks argue over what is the semantically correct markup for breadcrumbs, but when using an ordered list I think the "You are here" text should be outside the list as it doesn't represent a page in the site hierarchy.

By default ACE requires an opening PHP tag for syntax highlighting to work, even when set to PHP mode. But there is an 'inline' mode that enables highlighting without needing the opening tag: https://github.com/ajaxorg/ace/issues/2542 Is it possible to set this inline mode via the API for Inputfield ACE Extended?

Just an ordinary textarea - make sure the Inputfield Type is set to "Textarea" and not "CKEditor. Don't add any textformatters to the field.

You might be interested in this recent thread about rendering page content to an 'index' field with a save hook. I only tested it briefly but with this approach you are in control of what is saved to the index - so for Page fields for example you can save the title or any other subfield you want.