adrian

I think this approach is reasonable: if(wire('user')->roles->has("name=".implode("|",$this->data['allowedRoles']))) { I think a little cleaner than array_intersect in this situation.

I don't think that error is because of wire('roles'). If you take a look at line 730 of that file (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessModule/ProcessModule.module#L730) it's about foreaching through all the fields in your modules config setup. I have tested that code and it works fine, so I think you are likely missing something else in your config setup. There are different ways to set up the config, but this should work: protected static $configDefaults = array( // global "allowedRoles" => "" ); protected $data = array(); public static function getModuleConfigInputfields(array $data) { foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } $wrapper = new InputfieldWrapper; $f = wire('modules')->get("InputfieldAsmSelect"); $f->required = true; $f->attr('name', 'allowedRoles'); $f->label = __('User roles allowed to flag'); $f->setAsmSelectOption('sortable', false); if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; // populate with all available roles foreach(wire('roles') as $roleoption) { $f->addOption($roleoption->name); } $wrapper->add($f); return $wrapper; } Or if you are still having problems, feel free to post your entire code so we can take a look.

Not paranoid at all. This is paranoid - I have actually gone as far as renaming my .htaccess file to something else so if some script did manage to get access to the server, it would be trying to edit a file that doesn't exist BTW - Not suggesting people need to do this - it is a bit of a pain to maintain. I started doing it a long time ago after a server got hacked and I went a little overboard

Here are the recent changes to the htaccess file: https://github.com/ryancramerdesign/ProcessWire/commit/30495a970e7a0efcf67610543131a8735870a9b6 But I am not suggesting that you need to use the old one - you just need to edit the new one with the correct RewriteBase setting. That's assuming that is actually the problem, which it may not be, but it is the first thing you should check when seeing that error.

Hi jeve and welcome to the forums. I really don't have much advice for you, but it would be good to know what version of PW you are running and also your PHP and MySQL versions. Also are you using any PW caching options? Any change you have a isLoggedin() check in the bootstrapped file that is expiring? Could you show us all the code from your bootstrapped file. There were some selector issues in a recent dev version of PW when bootstrapped, but these have been solved in the latest version. I am sure we can figure this out with a little more information.

Good luck with restoring things and with all the deadlines and please let me know when you have a chance to check the Migrator version and send me that JSON file so I can test and sort out a better solution for page fields that handles all situations.

Ok, so I just tested with CustomUploadNames installed and even with it set to "Rename on Save" and it all seems to work fine after editing with Pixlr Editor, so my current theory is that you are running an old version of CustomUploadNames. Can you please try with the latest version and let me know. If you're still having trouble, I'll investigate further. @PawelGIX - on another note, you should update the module to set the status of the Pixlr Image Process page to hidden so it doesn't appear in the Pages dropdown menu which is part of PW 2.5 (you can see what I mean in recent dev versions).

Looks like that might be the trouble! I haven't evert tried PixlrEditor but I'll take a look now and see if I can sort out a fix for you. What are your settings for CustomUploadNames? In particular your FileName Format and Rename on Save settings? I think it is most likely the "Rename on Save" setting that is causing the problem. Try unchecking that first. I will also test here too. Also, what version of CustomUploadNames are you using - please make sure it is up to date.

Now available in the modules directory: http://modules.processwire.com/modules/password-force-change/ For anyone who might have downloaded early on, please grab the latest version. There was an important fix two days ago that now prevents users from simply navigating away from their profile page to another page in the admin. Now they can't do anything in the admin until their password has been changed.

https://processwire.com/talk/topic/52-how-do-i-upgrade-processwire-to-the-latest-version/ Definitely no data loss

EDIT: Looking at all those new posts above (should have checked before I sent my post), it looks like I was not on the same page

Wow - I am not very observant today am I I think it likely is the issue: https://processwire.com/talk/topic/4651-cant-delete-or-modify-repeater-item/ There is another post where Nico suggests upgrading to 2.4 and I think that fixes the issue for the OP, but I can't find it right now. Regardless, you should really be running 2.4 - lots of amazing new things

What version of PW are you running. There was another recent post about deletion of repeaters via the admin and it turned out to be a very old PW version?

Oops - nice catch horst. That's what you get for copying and pasting from different things in a hurry I would recommend removing the first one. The approach in the second one insures you won't get an "Undefined index: allowedRoles" error before any roles have been chosen.

Glad you got it working. Just to clear things up for people searching the forums, I just edited the title of this post from the original: "How To Use A Method From Another Module In Own Module" since this is more specifically about image fields. I don't think it really is documented anywhere at the moment - definitely something that should be explained somewhere.

This should get you started: $f = wire('modules')->get("InputfieldAsmSelect"); $f->required = true; $f->attr('name', 'allowedRoles'); $f->attr('value', $data["allowedRoles"]); $f->label = __('User roles allowed to flag (use spaces to separate entries)'); $f->setAsmSelectOption('sortable', false); // populate with all available roles foreach(wire('roles') as $roleoption) { $f->addOption($roleoption->name); } if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; $wrapper->add($f); I see you are using owzim's config helper, which I haven't used, so let us know if you have any trouble incorporating it into your module.

Hi marcus - sounds like a great addition. How about making it an ASM field that grabs all the available roles?

What Soma is getting at is that because you are in a module context, the "image field to 1 max image" setting doesn't work to convert the image field from an array to a single image, so you must use first(). eg: $bgImg = $s->section_img->first(); Here's a worthwhile read: https://processwire.com/talk/topic/1125-images-field-returning-array-even-when-max-files-set-to-1/

I doubt it's your fault. Behaviour of copying pagefield content is actually something I am struggling with for Migrator (and the main reason I haven't "released" it yet). The current behaviour is to automatically create the required templates and pages for any page field that is part of a page that you chose to migrate. The problem is where to put these page field pages. If they are not within the page tree that you are migrating, or if the parent they are under is not available on the destination site - what to do? I think the desired behaviour may be different depending on whether you are migrating content from a dev version to a live version of the same site, or whether you are importing content from one site into another one that doesn't already have the page field content in its structure. I hope that makes sense - even I am having trouble understanding what I just wrote That definitely sounds like the issue. It's not the importing of users/roles that created the content (Migrator handles this well), but rather the problem of trying to re-create the users that are selected in that select page field. I'll obviously have to revisit my current approach to migrating page field content, especially for scenarios like this. The problem is that if the page field pages are not under the exported parent and you don't include them, then that will result in broken page fields on the destination site. What to do ? I'll marinate on this for a bit, but I'd also really appreciate any thoughts! Macrura - if you feel like testing, I'd really appreciate knowing if everything works fine if you remove that page field from the site before you export. It should work fine with other page fields, but the linking to users must be the issue. Thanks and sorry for the hassles! EDIT: Would you mind PM'ing your exported json file so I can see exactly the structure of the page field? I am thinking that maybe an option would be for the export to contain the full page path to the pagefield's content pages and if that path exists on the destination PW site then use that. If not, then create these pages under the Home page. Hopefully this can be solved in a logical way that works in all situations.

Not sure if this is definitely the issue, but often the default RewriteBase don't work depending on server configuration. The most common requirement is to simply uncomment the first example option: Rewritebase / but you might need a different config. It should however be the same as you had it set up when running the 2.4.4 version of PW. Maybe it is something else that is causing your problem though?

There is also this module which might be useful to you: http://modules.processwire.com/modules/service-pages/

That's not what I want to hear Are you using the latest version of Migrator? Can you send through that entire error message (all 70 rows of it)? What happens if you go back to PW 2.4 - wondering if there is a difference without Lister being used to display users.

@Andrei K - welcome to the forums! Nothing should have changed re PHP or MySQL versions. I think the most likely issue will be the RewriteBase setting in your .htaccess file. Did you replace this with the new version but forget to make a required change to the RewriteBase setting for your server?