adrian

Yep - I see that it totally works with PW tables. Thanks for looking into an option for non PW tables. I am actually wondering if you might be able to do something like: $page->selectextoption->db_field_name and be able to return the value from any field (column) for the row that contains the selected integer ID value? This could work with both PW and non PW tables. Some examples of what you could return with this. PW fields table: $page->selectextoption->id = 1 $page->selectextoption->name = title $page->selectextoption->label = Title $page->selectextoption->flags = 13 a non PW table (maybe a list of country codes): $page->selectextoption->num_code = 276 $page->selectextoption->iso3 = DEU $page->selectextoption->name = Germany I think this would be much more powerful than just returning the value and label fields. I think it might also be nice to be able to magically return the selected value and label without knowing what the fields are, so: $page->selectextoption = 1 $page->selectextoption->selectedLabel = Title (assuming the field I chose for the label was the title field) Of course you can't use "Label" in this last example because "Label" is a field name in some PW tables, hence my use of "selectedLabel", but there might be a better option. Does that make sense? Thanks for your hard work on this - it's going to be very useful!

I know this is a very late followup, but I recently posted an alternative over here: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89599 and https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89616 Pros and cons to each version, so you should read all the posts in between as well. Personally I would go with the second one, just be aware that if you want it to work on the front-end you need to consider the name of your form fields.

Now another new notice: Notice: Undefined index: option_table in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 145 You really need to turn on debug mode, or at least check your php error log I see why you went with integers for the value - it makes sense to stay with the schema of FieldtypeMulti - I hadn't thought of that. But when using a non-PW DB table, when outputting the label of the selected value on the front end of your website, how are you going to get the value you want to display? This will require an SQL query to retrieve, right? For some devs this is no problem, but for others it may be too technical. Do you think you could include a method for rendering the label on the front end, based on the stored value? I am thinking that you should be able to do: echo $page->selectextoption; and get the label of the selected value, rather than the stored value. What do you think?

That suggest to me that 105 is maybe missing a semi-colon at the end of it. But I am sure you haven't edited that file. What happens if you replace it with an original version of the index.php file?

Here is something I hacked together quickly for automatically adding new child pages to the pagetable field. This is only if you are using the page as the parent. It also handles deletion of items if they are trashed externally. I also disabled the internal check for orphans - because they have been automatically added already, there is no need for the "Children were found that may be added to this table. Check the box next to any you would like to add." option. I seems to be working great here, but please test carefully!! Add this to your admin.php file: wire()->addHookBefore('InputfieldPageTable::render', function($event) { $pp = wire('pages')->get(wire('input')->get->id); $ptf = $event->object; //remove pages from pagetable field if they were externally trashed foreach($pp->{$ptf->name} as $item) { if($item->is(Page::statusTrash)) $pp->{$ptf->name}->remove($item); } //add pages to pagetable field if they were created externally foreach($pp->children as $child) { if(!$ptf->has($child->id)) { $pp->{$ptf->name}->add($child); $pp->of(false); $pp->save($ptf->name); } } //reset orphans property so that we don't get a message asking to add new pages that are now already automatically added $ptf->setOrphans(new pageArray()); });

PageLinkAbstractor has been deprecated (Ryan has removed it from the modules directory). The core PagePathHistory is his preferred approach to dealing with changed URLs now.

Awesome enhancements - this is very cool! Still getting one notice: Notice: Undefined variable: v in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 109 Can I make one suggestion - if the option label field is blank, could the label use the value field? PS Is there any reason for the "type (int)" part of this description "Choose a column of type (int)." ? Why can't I use a text field? I am guessing it is just suggestion, and while it is generally a good idea, there are often reasons this is not convenient.

You should also check out Bea's new module - it is much more powerful and stable than the one I mentioned above and I think would be a great fit for your needs: https://github.com/justonestep/processwire-imageextra

That fixed it! Everything seems to be working again now - just a pesky notice: Notice: Object of class WireArray could not be converted to int in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 105

Well you could create a new Pageimage from the image path: $image = new Pageimage($page->images, "/path/to/image.jpg"); Then you could run sizer on the page image. Then delete the pageimage if you want. I think something like that should work. Either that, or just use standard GD commands.

Assuming BitPoet is correct and that is your problem, then it should work after that. Nothing wrong with doing it manually obviously, but just an FYI - there is a module for grabbing video images from YouTube/Vimeo and populating an images field, along with descriptions: https://processwire.com/talk/topic/4614-youtube-and-vimeo-thumbnail-grabber/

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.