adrian

You're welcome and glad you like the module - I know I can't live without it Process modules need to extend "Process", not "WireData". You also need to tell it to create the admin/page/setup/blacklisted page. You can do this manually in the install method, but there is a much easier option which you can read about here: https://processwire.com/blog/posts/august-2014-core-updates-4/#process-modules-are-now-a-lot-smarter Am I right in assuming the idea of the Process module is to list (or allow editing) of the blacklisted page names? Let us know if you still need help. PS - there are lots of modules in the modules directory that are labeled as Process modules but really aren't. I am as guilty of this as anyone - I just didn't understand it all in the beginning and don't want to rename them now as it would break user's updates.

You could also override the javascript name checker so that you could warn users before they save the page. Take a look at this module: https://github.com/adrianbj/PageRenameOptions which also overrides that JS - it might help to get you started on the right path more quickly. Obviously this approach should be in addition to server-side checking, rather than a replacement for it

No, it's much simpler than that. You just add it once to the top of the file. <?php namespace ProcessWire; That's it - now there will be no need for the module to be compiled.

https://processwire.com/blog/posts/hello-健康長壽·繁榮昌盛/ Sorry, that is page names, not filenames Now that we have UTF8 pagenames maybe it is time to revisit UT8 filenames. Perhaps a request on the github requests repo?

I think there are a couple of approaches - you could concatenate the separate fields and save that to the map marker field when the page is saved, or you could parse the address from the map marker into the separate chunks to output in your template file. Do you have an idea which you might prefer?

Take a look at what I did here: https://github.com/adrianbj/AutoContent/blob/24ec931771d8e80f1e2b7fbd57bd774fedbddd0f/AutoContent.module#L305-L307 $pageimages = $this->getBlankValue($p, $field); $this->fakerImage = new Pageimage($pageimages, $imagePath); which makes use of this: protected function getBlankValue(Page $p, Field $field) { $pageimages = new Pageimages($p); $pageimages->setField($field); $pageimages->setTrackChanges(true); return $pageimages; } Obviously a bit of a hack, but it seems to work fine. Not sure if this would work for your needs or not. You will of course need a $field object for file/image field. EDIT: Sorry, that still needs a page: $p - I didn't notice that when I posted.

@LimeWub - if you add the ProcessWire namespace to your module and template files they won't need to be compiled and therefore won't be stored in the assets/cache/FileCompiler folder. All references to wire will work without needing \ProcessWire\wire But also remember that the version in that folder is updated every time you make a change to the original file anyway, so I guess I don't really understand the problem.

I just installed this on a site a couple of days ago and got the same error. I took the lazy approach of just adding all the fonts from the mpdf github repo: https://github.com/mpdf/mpdf/tree/development/ttfonts

Could you create a dummy page object with $dummyPage = new Page() and use that with new Pagefiles($dummyPage) Are you working with a hook here, perhaps InputfieldFile::fileAdded ? If so, you can get the field the file is attached to with $event->object->field If that's not helpful, maybe give us a little more context.

I love the case changer - awesome for when you've pasted in a title from elsewhere - thank you!

@microcipcip - "selectorValue" as the sanitizer is correct so I don't see any issues with what you have done. I am curious though - are you using that getSelectors() function elsewhere, or just calling it the once? If just once there is no real advantage to making it a function. Also, you might find the array approach to selectors easier in this case. Have a read here: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#new-selectors-as-regular-arrays

Hey @tpr - have a weird situation where one of my sites stopped showing the page IDs in the list view. With all PW and AOS versions the same it still works on other sites. I found a fix in the addPageListIDs() function. This seems to work on all sites: $event->return = '<span data-pid="' . $page->id . '" class="label_title">' . $event->return . '</span>'; although with my limited testing I am not really sure why there wasn't already a span with the label_title class applied to each title in the list view on this particular site. I am guessing that my approach might affect other modules that also modify the title in the list view, so you might need to investigate more thoroughly. On another note, I sometimes find that the template link in the page list actions doesn't always show for certain pages. It seems random and a page reload fixes it - maybe you have also noticed this?

Maybe it's a small site in terms of visitor numbers, but I wouldn't want that to be my inbox

You need wire('sanitizer') or $this->wire('saniizer') or $this->sanitizer when you are inside the scope of a function. It doesn't have anything to do with bootstrapping PW like you are doing there by loading a file that is not in the root of the templates directory. Have a read here (https://processwire.com/blog/posts/processwire-2.6.21-upgrades-comments-more-on-pw-3.x/#more-updates-on-processwire-3.0) for more details of what works where.

Sounds good - I guess it's really only issue if you are editing a file that is an autoload module, or perhaps a hook in something ready.php that is run whenever the admin loads. As @fbg13 noted that actually isn't working for some reason. I tried two different servers. As initial glance I am not sure why. I have used that 'page' => array approach successfully myself, although never in a info.php file - I wonder if perhaps that isn't working properly?

Hi everyone, I just installed this for the first time to help debug something on someone's site and thought this would be the easiest way to edit module files without asking for FTP access. It worked great until I saved the file with a syntax error and then needed FTP access to get anything working. This is more of a heads up than anything. Not sure what a workaround might be. Tracy's TemplateEditor Panel allows testing file changes, but this only works for the template file of the current page. Not sure how this could be done for other files - seems unlikely, but I'll have a think. The other thing I wanted to report is that the Setup > Files Editor page is not being created on install. I tested on another PW site and the same thing. Once I manually created it, everything worked fine.

Hi @HerTha - thanks for the report. I am having trouble reproducing here at the moment. Any chance you could give me access to the site to test? If not, could you help me figure out why $np is not being set properly. Line 1311 is where that should be happening. Not sure your level of debugging skills, but any chance you could take a look and find out what $np is being set to there. And if nothing, check the $value of $x for me. This shouldn't be hard to fix, but until I can reproduce it might be tricky. Perhaps it also might help if you post your csv import settings.

Sounds like a file permissions issue. Make sure the owner and permissions are correct for the /site/ folder and based on that error especially for the /site/assets/cache/FileCompiler/ folder.

Thanks for this - looks great, but curious if you know if they have plans to start charging ? I didn't see anything on their website (http://www.resmush.it/) to indicate the long term plans.

Yeah, that is what I have done in the past - no problem with editor role users making new pages - just need to set the template permissions correctly.

You shouldn't get yourself in a situation where you have some children that are part of a menu and some that are part of a PageTable field - it will be a terrible mess. Avoid this by designating an alternate location for storing the pages for the PageTable field - somewhere under a hidden parent, or even under a dedicated parent under Admin.

Add an expiry_date field to the "user" template and then check the user's expiry date against the current date before showing them the page.

Yeah, no flicker, just disappears if I don't move carefully (or quickly) from the button to the dropdown. Don't worry too much about it - I'll just disable that tweak.

I think the "Show save dropdown on hover instead on click" option needs to have a little delay before it's hidden. At the moment I think it takes some careful mousing to get from the button to the dropdown options without them vanishing. Too much dexterity required for some users.

Nope, if they exist they will be processed.