adrian

In this what you mean?

Done! Access to that PW install would be helpful - thanks!

Thanks @gingebaker - I have applied your curly brace fixes. Please let me know if you have any further troubles.

Hi @Barido - thanks for reporting. Sorry for the delay - I was on vacation. Can you please test the latest version and let me know if that fixes things for you?

Just for reference, here is the origins of that module:

Yeah, sorry about the frequency of updates But in all seriousness you might want to take a look at: https://github.com/adrianbj/ProcessModuleToolkit It's not officially released because there are some outstanding issues I haven't managed to get back to, but one thing it does (it has lots of features), is that it adds a "Batch Upgrade Modules" button to Ryan's Upgrades module. This makes upgrading multiple modules super quick with one click. It also makes installing modules with your preferred config settings really easy. Lots of great options. I guess I really need some more interest from you guys to get the motivation to finish it off.

Have you tried fixing the cause of that warning: https://github.com/USSliberty/Processwire-site-indexer/blob/master/Indexer.module#L186 It would be good to know if that warning is gone whether everything works as expected without debug mode on.

Try this: $publi = $pages->find("template=publication, author.name=".$page->name);

I just added a new Metadata section to the Mail panel, as well as linking the attachments so you can easily check them. Note that the Metadata section has currently only been tested with @horst's WireMailSmtp module. Please let me know if you have any problems/requests for use with wireMail's default use of PHP's mail() function, or @teppo's SwiftMailer module.

@fuzendesign - looks like your issue has already been reported: https://github.com/ryancramerdesign/ProcessWire/issues/1965

You can do a $modules->isInstalled("ModuleClassName") check in the template file and do your own error / notification handling.

Try the dev version of the imageExtra module - it has had some recent critical fixes.

Log entries are in files, not the db. You can delete or prune via the admin:

I can't see anything there that would cause a problem. I would suggest trying that snippet of deleting images on its own to make sure there is nothing weird with your install. I just checked with PW 3.0.29 via the Tracy console and had no problem. If this works for you (which it should), have you tried limiting your script to just a few lines of the CSV? Also, have you tried using PHP's max_execution_time option - I use this quite often when running custom import scripts.

@hansv - are you using the default images field, or have you added a third party cropping module or the imageextra module?

Maybe this: https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/#major-optimizations-to-inputfield-forms

Can we see all the code - I can't see where $has_image is defined. Also, any chance the entire thing is in a loop? Not related, but I have never seen this approach before: if(!$product->parent){ Normally you would use: if(!$product->id){ Also, do you ever set the title for the new product page? One final thing - the Croppable Image fieldtype does not support PW 3.x - does everything work without the error if you switch to a normal image fieldtype?

Certainly doesn't hurt to try. I would also suggest that saves within the $has_image check could just save the image field, like this: $product->save('image');

Not wanting to hijack this post, but could you provide more info about this - sounds like something I need to fix in Tracy. PM me if you like rather than polluting this post even more.

A minor enhancement to the PW Info panel - it now shows the content of UrlSegments. This is what you see for this URL: http://pw3.dev/cms/processwire/?rated=one&star=five It's only the UrlSegments in the Summary section of the PW Info panel that is new, but I wanted to also point out that in the Tempate Info section is lets you know if URL Segments are enabled for the template. Also, you'll see that the URL has a couple of additional GET parameters - these are listed in the Debug mode panel - they possibly belong better in the PW Info Panel, but the debug mode tools in the PW admin list them here so I kept them this way for consistency. Note that POST variables are also shown if they are present - this can be very handy when debugging form submissions.

Here are the two relevant bits of code showing how the optional parameters are defined https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/core/Permissions.php#L35 https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/core/Permissions.php#L85

Yes, you are checking for its presence correctly. I think you will just need to manually add the title as well. Take a look at the function that installs those optional permissions via the admin interface: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L108 Notice where it adds the title: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L133 $permission->title->setLanguageValue($language, $a[$name]); but of course you don't need to worry about the language.

https://github.com/ryancramerdesign/pw28

You should never rely on client side validation on its own. Server side is a must! Not to say you shouldn't use client-side, but it should only be for a faster/nicer UX, not the ultimate check.

What happens if you simply remove this line: $user = wire('users')->get('user'); That is setting $user to a user named "user". If you are wanting to change the password for a user that is not the currently logged in one, then don't overwrite the PW $user var, instead use $u or something else.