adrian

Awesome to have the multi options. A couple of things. Instances of page_id should be pages_id Are the defaults supposed to work if not entered? They don't seem to - even if I change $value = 'page_id' to $value = 'pages_id' in the getExtOptions function, it still gives me "Column doesn't exist in table" With this new version I am getting "TemplateFile: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'sort' in 'order clause'

Wow - sorry about that - very old instructions when the module had a different name - I'll update those in a minute Glad it's working for you now!

I think DaveP is correct - sounds like maybe you didn't install ProcessMigrator is the "normal" way. MigratorWordpress needs to see that MIgratorAbstract.php file inside modules/ProcessMIgrator I could probably change things up so that this path can be different, but please check if setting things up like that works as expected. BTW, the easiest way to install a module that is not in the PW modules directory is to use the "Add Module from URL" option and point it to the Github "Download Zip" link, eg: https://github.com/adrianbj/ProcessMigrator/archive/master.zip

I think PageRenameOptions should be able to help you out - just use the "Prevent Manual Changes" option. Or, you could make use of Martijn's AdminCustomFiles to insert this JS (which is what PageRenameOptions uses): $(document).ready(function() { $('.InputfieldPageName input').attr("readonly", "readonly"); }); You would attach it to: ProcessPageEdit

Just committed some new features: New checkbox "Send welcome message" added to the bottom of each user page - uncheck to NOT send the email to a new user. You can use this checkobox to re-send a user's welcome email if needed. You can edit the welcome message template for each user as you create and save the user. Also some better error reporting, and detection of PasswordForceChange. Please let me know if you have any problems with this new version.

That should work and works fine here. I am wondering if there is some issue with the "hundreds of pages"? How many fields are there in the template? One thing to try might be to: $page->save("new_field"); since this only saves that one field, rather than all of them. I don't think it is necessary in this case, but it is always good to do: $p->of(false); before saving. Are there any errors being logged?

Very cool - definitely has some similarities with: https://processwire.com/talk/topic/8803-module-fieldtypeselectrelation/ but the ability to draw from any type of DB table is super cool and really flexible - I love it and can see several uses for it already Any thoughts of making it support ASM multiselect? This could then replace http://modules.processwire.com/modules/fieldtype-templates/ and https://processwire.com/talk/topic/9167-create-a-field-for-selecting-fields/?p=88679

Check out this post from Ryan where he explains how to use: ProcessPageEdit::buildFormSettings https://processwire.com/talk/topic/510-name-field-in-content-instead-in-settings-tab/?p=4830

Hi shawnadelic and welcome! Check out soma's new module: https://processwire.com/talk/topic/9299-pollino-simple-polls-for-processwire/ There really is no fool proof way of ensuring this sort of thing. Cookies can be cleared, IP addresses are usually not static and can be spoofed anyway. The best option is to require the user have a user account and that they be logged in, but if you are not concerned with complete accuracy, you can make use of a combination of techniques, which I believe soma's module allows for. Even if the module doesn't suit your needs exactly, I bet you will find lots of useful code snippets and ideas in there. I have built a couple of polls, one that relied solely on cookies, and one that required the users to be logged in, but have never gone the IP route, because in particular it might prevent users from the same house, place of work, or even the same ISP being able to vote.

No problem. Also, as a somewhat cleaner alternative to what I posted above, you can grab the POSTed version of the username directly to avoid the need to replace "-" with "@". With this version, it doesn't have to do anything if there is no "@" in the entered username. public function init() { if (strpos(wire('input')->post->login_name, '@') !== FALSE) { $this->addHookBefore('Session::login', $this, 'beforeSessionLogin'); } } public function beforeSessionLogin(HookEvent $event) { $name = wire('sanitizer')->email(wire('input')->post->login_name); $u = wire('users')->get("email=$name"); if($u->id) $event->setArgument('name', $u->name); } This way you can choose to sanitize it as an email address before it has been sanitized as a pageName which doesn't allow "@". The disadvantage to this version though is that for the front-end, you need to make sure your custom login form also uses "login_name" as the name of the input field. Not a big deal, but not as versatile I guess.

Well actually, that hook and function I put together also works perfectly on the front-end, as well as the admin - I assumed you wanted both. All you need to go is use that as part of a module and then be sure to load the module in your login.php file for it to also work on the front-end. But if you only need front-end, then Jan Romero's version is simpler.

Sorry about that - good point. I think the problem with what you're trying to implement is that @ is not allowed in name fields. This is a bit hacky, but seems to work fine and allows a user to log in with either their name or email address. Keep in mind there will be issues if you have more than one user with the same email address - email is not a primary/unique fieldtype so even though there are checks to prevent a user from changing their email to one that already exists in the system, it is still possible to create two users with the same email via the admin panel if you are setting them up. It replaces any instances of "-" with "@" and checks to see if it can find the user with that email address. If there isn't a match, it processes the name with the "-" just in case there is a user in the system with a name that contains a "-", which is allowed. public function init() { $this->addHookBefore('Session::login', $this, 'beforeSessionLogin'); } public function beforeSessionLogin(HookEvent $event) { $name = $event->argumentsByName('name'); if (strpos($name, '-') !== FALSE) { $email = str_replace('-','@',$name); $u = wire('users')->get("email=$email"); $username = $u->id ? $user->name : $name; $event->setArgument('name', $username); } } I put this together pretty quickly, so can anyone think of any major issues with this?

Take a look at this thread: https://processwire.com/talk/topic/1838-login-using-e-mail-rather-than-username-and-general-login-issues/ There is a module for allowing login via email address, but be sure to read through the read, especially the posts by Ryan about potential issues with logging in via email.

I just committed an update that brings full support for repeater fields (images and images embedded into RTE fields inside repeaters). I also fixed a bug with the new core cropping functionality if you set a filename format that is not available on file upload, such as $file->description. There were some significant changes to hooks and logic to get the repeaters working, so please test and let me know if you come across any problems.

This is what you are looking for: $this->pages->addHookAfter('added', $this, 'hookAdded'); public function hookAdded(HookEvent $event){ $newPage = $event->arguments[0]; $this->message('it worked here is the id of your new page:'.$newPage->id); // Yes, this will work }

I haven't tested yet, but it looks very impressive - awesome job!

Nice one ESRCH, but that only affects the View tab on editing a page - I also like to change the view links on the page tree. Yours does cover the only critical issue as that is when it is possible to lose changes to a page (unless you have Soma's Form Save Reminder installed). I just posted this over at: https://processwire.com/talk/topic/7588-admin-custom-files/?p=89331 because it uses Martijn's Admin Custom Files. This version also changes the view links on the page tree. ProcessPageList.js $(document).ajaxComplete(function(){ $('li.PageListActionView a').each(function(){ if($(this).attr('target') == undefined){ $(this).attr('target','_blank'); } }); }); ProcessPageEdit.js $( document ).ready(function() { if($('#_ProcessPageEditView').attr('target') == undefined){ $('#_ProcessPageEditView').attr('target','_blank'); } }); Maybe someone else will also like this approach.

HI Astatek and welcome to the forums. By default, image fields can contain more than one image, so they will return an array of images, even if only one is uploaded. The simplest option is: $agent->images->first()->url but if you choose to change the setting on the image field's Details tab - "Max Files Allowed" to 1, then you could remove the need for the "first()". You can also adjust what will be returned when formatting is on by adjusting the "Formatted Value" options. You should have a good read through http://processwire.com/api/fieldtypes/images/ to get a better understanding. Hope that helps.

Thank guys for this module - it was great to quickly set up a ratings system. A couple of thoughts though. I am not sure why it needs to be an autoload module - I'd rather you simply load it manually in a template file when you want to use it. I am not sure why it isn't simply a custom fieldtype that can be added to templates as needed - the way you have done it seems to work just fine, but the one issue I am having is that it can't be used as easily in all situations - for example, you can't select "rating" as an option when configuring a custom view with ListerPro. I am sure there are also other situations where it would be preferable to be a fieldtype, but maybe there are advantages to the approach you have taken that I am not thinking about. Of course if #2 is implemented, then #1 is no longer an issue Any chance you'd consider a bit of a rewrite to make it a fieldtype? if not, please let me know and I'll put something together myself - just trying to avoid duplicate modules that do the same thing Thanks for considering.

Doesn't this need to be broken up into two files, or am I missing something? ProcessPageList.js $(document).ajaxComplete(function(){ $('li.PageListActionView a').each(function(){ if($(this).attr('target') == undefined){ $(this).attr('target','_blank'); } }); }); ProcessPageEdit.js $( document ).ready(function() { if($('#_ProcessPageEditView').attr('target') == undefined){ $('#_ProcessPageEditView').attr('target','_blank'); } });

I have actually started using this version so that the links only show on hover and are hidden from the parent when a branch is open: .content .PageList .PageListItem:hover .PageListActions{display:inline;-webkit-transition-delay:.25s;transition-delay:.25s} .content .PageList .PageListItemOpen .PageListActions{display:none !important;} .content .PageList .PageListItemOpen:hover .PageListActions{display:inline !important;-webkit-transition-delay:.25s;transition-delay:.25s} In addition to quicker access and less confusion, it is also a huge performance increase on slow internet connections (I just spent a few months with horrible internet) because you don't need the ajax call to retrieve the child pages just to be able to edit the page, or add a new child.

Hey Ivan, I just committed a fix, although in a hurry, so not tested, so please let me know if it works for you as expected. Actually curious why you are using $page->title rather than $page->name - wouldn't it end up being the same thing?

"Custom Script" - does that mean your code is not in a PW template or module file? Have you bootstrapped in PW so you can access its API? https://processwire.com/api/include/

For the moment, the easy fix is to create that DB field (data1020) yourself in the field_title table. Are you comfortable with PHPMyAdmin or similar tool, or command line SQL?

I am not sure if maybe this problem is back, or certain MySQL configurations are still causing issues. Here is some further reading: https://processwire.com/talk/topic/8759-cannot-add-new-language-in-latest-dev-bug/?p=88530 https://processwire.com/talk/topic/5286-switching-fields-to-language-fields-produces-fatal-errors/ I'll make sure it is made aware that this still seems to be an issue. What version of MySQL are you running?