adrian

Just because it looks like valid json doesn't mean it's in the correct format for Migrator. But could you please make sure you are using this version of Migrator: https://github.com/adrianbj/ProcessMigrator/tree/3e2121b8fdb68e9d9dc0c6aca8aae75e923a2669 It is two commits behind, but it looks like some bugs were introduced since that commit. As an update on this project. I still do want to get back to it, but I am now going to wait until Ryan completes all the new core page migration tools so I can use those new core methods. Will wait and see exactly what functionality he builds and extend from there if needed.

Excellent - sorry about the new bug in the first place

Hi @flod, I have had users able to upload images no problem here. Could you perhaps help by debugging the error from the image upload. Your browser dev console's Network tab might show what is going on. Anyone else using this module having any problems with image upload?

Please try the version I just committed - I have just tested here on PW 2.7.2 and it's working fine. Note that I am using horst's WireMailSMTP module, but I don't think that should matter.

Nice first post Thanks for your contribution!

Thanks - I ended up changing a little anyway. I went with: $titleMultiLanguage = $this->modules->isInstalled("FieldtypePageTitleLanguage") && $this->fields->get('title')->type == 'FieldtypePageTitleLanguage'; because I figured in this case we need to be sure that the "title" field type is actually set to "FieldtypePageTitleLanguage" or we'll get a non object error when I try to use getLanguageValue() on it. Sound ok?

I think the issue might be the PW version. I started using $mail->new() which I think maybe wasn't available in that version. Could you please clarify that it works if you change that line to: $mailer = wireMail();

Does this do what you need? http://modules.processwire.com/modules/fieldtype-select-ext-option/

Yep!

Then go with child pages, or pull info from the file's description and tags fields. You could possibly put the date in the description and the type (Regular, Financial. etc) in the tags field.

I would strongly recommend not doing this with an RTE textarea - it is always going to be a mess I would suggest building the table in your template file with the API. You can iterate through the PDFs in the files field, or use a repeater, or even child pages if you need more info for each PDF. Let me know if you need some help with this.

@tpr - it's implemented, although a little differently because I didn't want "default" taking up so much space in the input. I went with a warning icon and outside of the input so I could add a title tag to it. I am checking if the "FieldtypePageTitleLanguage" module is installed before checking if there is a title in the user's language. Maybe one of the ML gurus can tell me if there is a better approach: $this->modules->isInstalled("FieldtypePageTitleLanguage") && !$cp->title->getLanguageValue($this->user->language) Let me know if this suits your needs.

As it says: "use pageName instead" /** * Format required by ProcessWire user names * * #pw-internal * * @deprecated, use pageName instead. * @param string $value * @return string * */ public function username($value) { return $this->pageName($value); }

I have committed a new version which: adds a new "From Name" field setting so that the email new users receive comes from your name/email, not just a raw email address. adds support for HTML body text. A plain text version will be generated automatically from this and both sent with proper headers. makes the parseBody method hookable, so you can define more complex field tag replacements. For example, this will accomplish @Timothy de Vos's needs: $this->wire()->addHookBefore('EmailNewUser::parseBody', null, function($event) { $page = $event->arguments[2]; $pageId = $page->location; $replacement = "http://".wire($pageId)->parent->name.".".wire('config')->httpHost; $event->arguments(0, str_replace('{location}', $replacement, $event->arguments[0])); }); Please let me know if you have any problems with this new version! Thanks to Timothy for helping to test this new version and as he noted, if you want full HTML support in the supplied CkEditor body input, you'll need to set: config.allowedContent = true

Sorry @Nukro - I haven't tested with multisite. Perhaps if you can point me to where the problem is I can figure out a fix. Unfortunately I don't have time at the moment to setup the multisite module to test myself. Let me know if you can narrow it down.

@Hantsweb - any chance you have the SessionHandlerDB module installed? @tpr - I wonder if in reality this should come under an overhaul for BCE to add multi-language support in general - maybe the edit interface needs tabs to make it possible to edit titles in all languages? Trouble is that I am really going to start running out of time for major module changes here. Anyone up for putting together a PR?

Just added a new "Email Batcher" action, which has the following features: Select recipients by user role, or using a pages selector for any pages on the site Parsing of field tags in the body so you can do something like: Dear {first_name} Option to send a test email HTML body, with automated text only version also sent Special {fromEmail} and {adminUrl} tags. Ability to hook EmailBatcher::parseBody to apply other custom replacements Don't forget TracyDebugger's Mail panel when testing - it will capture the outgoing emails (so they won't actually be sent): http://processwire.com/blog/posts/introducing-tracy-debugger/#mail-panel

I am a big fan of Forklift: http://www.binarynights.com/Forklift/ dual pane finder replacement ftp/sftp directory synchronizer

Have you tried: http://modules.processwire.com/modules/croppable-image3/

@Hantsweb - can you narrow it down to a certain branch of the page tree or does it happen everywhere on your site? What version of PW? What version of this module? What other modules do you have installed?

https://github.com/ryancramerdesign/skyscrapers2

I can't seem to reproduce, but it seems like it's related to this: http://stackoverflow.com/questions/22148080/an-invalid-form-control-with-name-is-not-focusable From a quick read of that, it sounds like the "width" field is hidden and required which doesn't seem to be the case for me. Is there any chance you have some JS that could be adding the html5 "required" attribute to this? Have you checked the generated HTML to see what's going on?

Thanks @kongondo - I was PHP was strict on function name case! I think I inadvertently copied the case of $fieldName through to the getPathname() method. Anyway, it's fixed in the latest version - thanks for noticing and pointing it out.

Blog post in Norwegian on setting up https with PW: https://www.asbjornness.no/blogg/https-med-processwire-hos-proisp/

I just checked Ryan's most recent commit (https://github.com/processwire/processwire/commit/43986173fb449bf0fb967a0d613896f2e3d6b4da) and the problem is now fixed for 3.0.48.