adrian

Minor, but useful update just committed. I noticed that the Console panel didn't have access to custom properties/methods added via hooks in other modules if they were added in ready() vs init(). For example, in the MarkupSEO module when trying to do this, I got null returned. d($page->seo); Anyway, this now works as expected and returns the "seo" property object. Hopefully you guys will find it useful also. If you grab the latest fork of the MarkupSEO module (https://github.com/adrianbj/MarkupSEO/tree/various-fixes-enhancements) you'll also be able to make that call in the Console panel when editing a page in the backend as well as the frontend page view.

Glad you got it sorted - I guess this is a side effect of adding .php to the end of the module filename. I guess this will be a bit of a pain for some users upgrading, but I think the php extension does make more sense so probably worth it in the long term.

Hi @dragan - does a Modules > Refresh take care of things for you?

I have updated many sites from 2.4 to 3 and most upgrades are seamless. The odd one has taken maybe half an hour to an hour to get everything working again. Setup a local dev copy, upgrade and see how it goes. You're missing out on so many new features ?

Would you mind pinging Ryan on that issue referencing my last comment https://github.com/processwire/processwire-issues/issues/480#issuecomment-390819243 ? Thank you!

@dreerr - I have exactly the same issue as you on Safari. I have mentioned it towards the end of this discussion: https://github.com/processwire/processwire-issues/issues/480 Basically there still needs to be work done on the UiKit layout. Perhaps you could add a comment there to get Ryan's attention again?

Also, if you're going to use a separate config.php file, I think it's worth considering the $config = array() approach seen here: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.config.php

Just a note here to say that repeater support is now fixed. A big thanks to @PWaddict for help testing these changes.

Quoting from the blog post that @Zeka linked to: "At present, you have to tell ProcessWire you want to use the functions API by setting $config->useFunctionsAPI = true; in your /site/config.php file. Though after more testing, we may make it enabled by default in the future. If you don't have that $config property set to true, the functions are still available, but you have to prepend "wire" to them, i.e. the more verbose wirePages() rather than pages()."

Not really as is because there are too many issues with a repeater's multiple subfields and multiple items. How would you format the csv file to support this? BCE does support multiple value fields though like Page reference, multiplier, etc with a multiple values separator in the csv. I guess it might be possible to use columns for the subfields and rows for the repeater items, but I think this is really of out the scope of this module. I think you'd be better off building a custom solution for your needs, maybe built on top of the AdminActions module.

That seems to be the issue - it seems one of my recent attempts to clean things up broke this part. I'll try to get it fixed soon. Thanks for all your testing of this module - it hasn't had any love for a long time and I have never actually used it with repeaters so it certainly needs it ?

@PWaddict - I have been testing here with repeaters a lot for the last few versions and it all seems to be working fine. Do you get the same issues on a new page starting from scratch? Just wondering if there are some effects of old images in existing repeaters instigated from an older version of this module? Also wondering if your Filename Format setting is contributing to the problem - what are you currently using?

Could you please narrow it down to whether it's due to no template file, the page being hidden, or because they're svg files?

I'd certainly give that option a go. I am not super au fait with these managed server setups - I mostly used dedicated servers or unmanaged VPS setup, but with my limited experience, I have found that FastCGI (which uses nginx) to be a problem with PW. That said I haven't seen that much about it on these forums (https://processwire.com/talk/topic/19405-502-bad-gateway-after-24-hours-live/) so maybe it was just me ? and maybe it's not the same issue you are seeing - just guessing really.

That's basically what is going on with Page Protector already so I don't see how it will help. If they reload the page and it churns for 30 seconds then I think there is something else going on. There are mod_fcgid settings that can be tweaked but as I mentioned above I tried for ages and never got anywhere. I think there is something between PW and nginx as a proxy for apache, but I couldn't figure out what it was. All the issues i had (which sound similar to yours) went away when I changed to a pure apache server (not FastCGI). Maybe others have been down this road and got things working. BTW - I didn't have PageProtector enabled and still had issues.

Do you mean browse on frontend, or try to access page editing in the backend? The backend issue is normal PW behavior when a session has expire. I guess because you are using Page Protector it's causing the same issue on the frontend. Perhaps the login persist module might help: http://modules.processwire.com/modules/login-persist/

Looks like the server is using nginx as an apache proxy. I have had a couple of PW sites on these setups and decided never again ? I could never figure out what the problem was and as soon as I moved to a regular apache system everything worked as expected. Maybe someone else out there solved it and can provide a solution.

@Crowdland Technology - thanks for posting that. I honestly think you should consider converting the upload form to be a little more ProcessWire-y. Take a look at the second set of code blocks (the ones that include the file field) in this post: https://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ I just tested CustomUploadNames with this approach and there are no errors. I think the problem you are having is related to unlinking, but it would be good to get confirmation on where that error you are seeing is originating from - a stack tracy from TracyDebugger should help with that - you might need to toggle strict mode on from the Panel Selector to get the trace because it's a warning rather than a fatal error.

Modules > Core > ProcessProfile

Probably obvious, but remember it is only enabled for superusers. Scratch that ? What exactly isn't working? Are you not getting detailed errors on the frontend, or does the backend not report debug mode on?

I am not seeing anything like that, but it might be something specific to your frontend upload form - it looks to me like it is trying to access the old filename. Could you share the code you are using? Is that error there in 1.0.9? PS - I have update the module to the last version I sent to you above.

Sorry, please try this one. ProcessCustomUploadNames.zip

@Crowdland Technology - please try the attached version. I don't have any time to test right at the moment. If that doesn't work as is, please also uncomment line 160. ProcessCustomUploadNames.zip

Hey @bernhard - I have a slightly revised version that tweaks the returned array to exactly match getallheaders(). I'll implement this is Tracy shortly unless anyone else has any better ideas. $headers = []; foreach($_SERVER as $name => $value) { if($name != 'HTTP_MOD_REWRITE' && (substr($name, 0, 5) == 'HTTP_' || $name == 'CONTENT_LENGTH' || $name == 'CONTENT_TYPE')) { $name = str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', str_replace('HTTP_', '', $name))))); if($name == 'Content-Type') $name = 'Content-type'; $headers[$name] = $value; } }

@Juergen and @simonsays - I think your issues should be fixed in the latest version. Please let me know.