Robin S

The module readme mentions a relevant option: You would set that to false if you don't want entities encoded.

You're missing parentheses. // Save $word->save();

Don't do this part... $p = $word; ...just work with $word directly to change its parent. If it still not working in all cases then focus on the step where you get the parent page: $parent = wire('pages')->get("parent=$page, template=exercise, name=exercise-$number"); There is no guarantee this will always return a valid page, so you might want to check that $parent has an id > 0 and if not log/dump $word->id or something so you can find where the problem is.

It's FileCompiler getting confused by strings containing the name of API variables next to parentheses. GitHub issue: https://github.com/processwire/processwire-issues/issues/98 A moment ago I was seeing the same issue as you for "File (for FormBuilder)", although after making a small edit to the module file (which triggered a recompile) the issue resolved and now I can't reproduce it again even after reverting to the original module file. I also can't reproduce the issue with "TemplateEngineTwig" so not sure what's going on exactly.

I reckon it's a bug. I opened a GitHub issue with a possible fix: https://github.com/processwire/processwire-issues/issues/627

I think you may need a semicolon inside the quotes. config.extraAllowedContent = 'p(tip);'; The CKEditor docs are not 100% clear about when semicolons are needed but you can see them included in some sample code here: https://docs.ckeditor.com/ckeditor4/latest/guide/dev_advanced_content_filter.html#custom-mode

Nothing is required outside of your module - make your module autoload and use the init() method in your module. The filename is not a property that is saved to the database - it is generated at runtime from the template name, so if you want to set a custom filename then this must be done at runtime. The comment in the Template class is clear about this: @property string $filename Template filename, including path (this is auto-generated from the name, though you may modify it at runtime if it suits your need). #pw-group-files

It is possible. I added example code to your GitHub request: https://github.com/processwire/processwire-requests/issues/204#issuecomment-400535558

I haven't needed to use pagefileSecure before, but it sounds to me like a permissions bug relating to the fact that non-superusers have limited access to repeater pages. There have been a few such issues in the past. Unless someone chimes in with a solution I suggest raising a issue in the GitHub repo: https://github.com/processwire/processwire-issues/issues

I use the following in /site/modules/InputfieldCKEditor/config.js to disallow inline styles. CKEDITOR.editorConfig = function( config ) { config.disallowedContent = '*{*}'; // All styles disallowed };

Yes, the handling of form errors is great now, thanks.

Thanks for the info. Hooking ProcessPageView::execute and calling getPage() seems to have negligible effect on response times. The method only executes once per page view, and getting the page object with getPage() method took an average of 0.0015 seconds in my tests. So I'm not too worried about that aspect. I'm not sure what you mean here - it might return the page object for a different page? Or some aspect of the page can be different? This gave me the same ID each time: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; for($i = 0; $i < 50; $i++) { $page = $ppv->_callMethod('getPage', []); bd($page->id, 'page->id'); } });

@pwFoo, if your page/template/file exists only to give some AJAX response then another approach you could consider is to hook ProcessPageView::pageNotFound. Then you don't need the page/template/file. In /site/init.php: $wire->addHookBefore('ProcessPageView::pageNotFound', function(HookEvent $event) { $url = $event->arguments(1); if($url === '/your-special-url/') { $event->replace = true; $event->return = 'your response'; } });

@pwFoo, note that you will also need to disable FileCompiler for the template. That's because FileCompiler forces the $config->paths->templates path at the start of the filename you set for the template, resulting in an invalid path if you used a full path outside of the templates folder for the filename. See here, here and here. You could open a GitHub issue for this - Ryan may or may not agree that it constitutes a bug.

I'm wondering about the intended or correct use of Wire::_callMethod(). I was tying out a hook to ProcessPageView::execute(), and I wanted to get the Page object that execute() was being called for. ProcessPageView has a getPage() method for that purpose, but it's a protected method so this doesn't work: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; $page = $ppv->getPage(); // ... }); But then I found Wire::_callMethod(), and this does work: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; $page = $ppv->_callMethod('getPage', []); // ... }); Is this a correct use of _callMethod()? Is this what _callMethod() exists for? The code comment for _callMethod() is... /** * Call a method in this object, for use by WireHooks * * #pw-internal * ...so the "for use by WireHooks" part sounds like my usage is okay, but the "#pw-internal" and the underscore prefix made me wonder if this method is only intended for use by the core. I couldn't find any mentions in the forum of anyone using it in their own code.

Is this custom login page for front-end users or for users who need to access the PW back-end? If it's for front-end users then I think you don't want them knowing about the core login page at all. You get a bit of extra security if you use a login page name that is not easily guessable (e.g. not "admin" or "processwire") and do not provide links to the core login page from the front-end. Then you only reveal the core login page to users who need to access the back-end. If the login page is for back-end users then I'm not sure why you would not want to use the admin-styled form given that the user is about to be working in the rest of the admin, but you could redirect away from it to your custom login page with a hook in /site/ready.php $wire->addHookBefore('ProcessLogin::execute', function(HookEvent $event) { $this->session->redirect('/your-login-page/'); });

The same code will work in a hook to Pages::delete. Adapted to keep it DRY: // Prevent the trashing/deleting of pages referenced by other pages $pages->addHookBefore('trash', null, 'protectReferencedPages'); $pages->addHookBefore('delete', null, 'protectReferencedPages'); function protectReferencedPages(HookEvent $event) { $page = $event->arguments(0); // Find non-system Page Reference fields $pr_fields = wire('fields')->find("type=FieldtypePage, flags=0"); // Implode for selector string $pr_fields_str = $pr_fields->implode('|', 'name'); // Find any referencing pages $referenced_on = wire('pages')->find("$pr_fields_str=$page->id, include=all"); if($referenced_on->count) { // Replace the trash/delete method $event->replace = true; // Link markup for referencing pages $referenced_on_str = $referenced_on->implode(', ', "<a href='{editUrl}'>{name}</a>"); $plural = $referenced_on->count > 1 ? 's' : ''; // Trigger an error message (using $session in case a superuser is trashing/deleting from ProcessPageList) wire('session')->error("You cannot $event->method page $page->name because it is referenced in a Page Reference field on page$plural $referenced_on_str.", Notice::allowMarkup); // Don't allow the trashing/deleting of this page $event->return = false; } }

A hook for anyone still wanting a solution for this: // Prevent the trashing of pages referenced by other pages $pages->addHookBefore('trash', function(HookEvent $event) { $page = $event->arguments(0); // Find non-system Page Reference fields $pr_fields = $this->fields->find("type=FieldtypePage, flags=0"); // Implode for selector string $pr_fields_str = $pr_fields->implode('|', 'name'); // Find any referencing pages $referenced_on = $this->pages->find("$pr_fields_str=$page->id, include=all"); if($referenced_on->count) { // Replace the trash method $event->replace = true; // Link markup for referencing pages $referenced_on_str = $referenced_on->implode(', ', "<a href='{editUrl}'>{name}</a>"); $plural = $referenced_on->count > 1 ? 's' : ''; // Trigger an error message (using $session in case a superuser is trashing from ProcessPageList) $this->session->error("You cannot trash page $page->name because it is referenced in a Page Reference field on page$plural $referenced_on_str.", Notice::allowMarkup); // Don't allow the trashing of this page $event->return = false; } }); When attempting to trash a referenced page from ProcessPageList the page will at first appear to be trashed but in fact it is not, and on the next admin page load a notice will be displayed explaining the situation. I don't think this detail matters much because it only affects superusers.

Yep, that's the only way I know of to customise the comments module.

Hi @ryan, The new field tag features are cool, thanks! It's not quite the same, but in some ways being able to use a different name (tag) to refer to a field in a selector is similar to a request I raised a while ago about an idea for field aliases. So for example if I have a field with a generic name like text_1, when it is in my employee template I can use it in my template file and selectors as first_name. That would help a lot with code readability and encourage more efficient field re-use. Could the new field tag features be leveraged in some way to add support for field aliases? Probably as a separate thing to tags, but perhaps building on some of the same code you added this week?

Hi @adrian, I'm still experiencing the issue below in the latest Tracy: I can fix it with the CSS I mentioned earlier... ...but it would be handy to have that as an option built into the module so no custom CSS is needed. Thanks!

Batcher is actually @Wanze's module - I just forked it to fix a couple of PW3 compatibility issues. Glad to hear that it's working for you now.

@OviS, I just tested the module in PW 3.0.104 and it is working fine. I think perhaps you have something configured wrong - double check that you are using the format virtual_parent_template=virtual_child_template in the module config and that both your virtual parent page and your virtual child pages are at the same level in the tree when the module is disabled. Virtual Parents disabled: Virtual Parents enabled: Or else perhaps another module or custom hook is interfering with the Virtual Parents module? You could test the module on a clean PW installation and see if you still have the same issue.

You could try out the idea for "Dynamic parent and/or template for pages created from the inputfield" outlined in this post:

You already have part of the logic for this - now you just need the else. I would tend to flip the logic around the other way though... if($p->id) { // $p is an existing page, so prepare it for saving new field values $p->of(false); } else { // No existing page so create one $p = new Page(); // ... } // Now set the field values of $p Keep track of the job ids in the RSS feed using an array. Then find any pages with job ids that are not in the array and delete them. $job_ids = []; foreach($rss as $item) { $job_ids[] = $item->id; // The rest of your code... } // Implode for use in selector string $job_ids = implode('|', $job_ids); // Find pages for deletion $delete_pages = $pages->find("job_id!=$job_ids"); foreach($delete_pages as $delete_page) { $delete_page->delete(); }