adrian

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.

Not exactly a changelog, but I have been thinking about adding a "What's New" section at the top of the API Explorer panel in Tracy. It would simply list any new methods or properties in the current version compared to the old version. Firstly, would you guys find this useful? Secondly, the catch with implementation is that Ryan doesn't seem to be using @since tags anymore - not sure if this is a recent oversight, or an intentional omission (https://github.com/processwire/processwire-issues/issues/759). If he gets back to me and starts implementing them again, I think that would be the simplest approach. Otherwise I'll need to cache the API explorer results and compare the current to the cached version (on PW upgrades). This isn't a big deal and I guess has the added advantage of showing all changes since your last upgrade (not the last actual version) so if you skip over a few versions, this will be more complete. So what do you think - would you guys make use of this? Can you see viewing the API Explorer panel after each upgrade to see what's new?

@celfred - sorry, looks like I forgot to commit that new 4.15.5 version - please try updating now - this new version should prevent the error.

@celfred - I just committed a new version that won't error even if there are old settings with panels that no longer exist, so please try updating and let me know how you go.

Oh now I see what's going on - the Template Editor panel hasn't existed in forever ? Your module settings must be configured to try to load it still. An uninstall/reinstall should remove those settings though. Maybe you had used the Panel Selector and "Sticky" selected the template editor? Could you please delete the "tracyPanelsSticky" cookie from your browser and let me know if that works.

@celfred - does that file actually exist? How are you upgrading / installing Tracy ? It's always safest through Setup > Modules > New or the PW Upgrades module. Also, if it's uninstalled and you're getting that error, then you probably need to do a Modules > Refresh

Thanks for letting me know about this - I didn't test the PR that went into 1.0.1 - it seemed like such a simple regex change ? Anyway, regex is now fixed and I have also removed the ancient and broken CURL code for grabbing the Youtube video title and replaced it with wireHttp()

Sorry about that - fixed in the latest version.

Great! Thanks, not sure when that happened - probably newly broken in UiKit theme. Should be fixed now.

A couple of updates to the new RequestLogger panel. You can now define which types of request methods are logged: GET, POST, PUT, DELETE, PATCH. By default, all are checked, but I think in most cases unchecking GET is probably helpful as it will prevent page views from being logged. You can now use this panel on non-ProcessWire pages, so if you use a php script like payment_confirmation.php in the root of your site, so long as it bootstraps PW (include ./index.php), it will let you log and retrieve request data. The only catch is that you need to trigger the logging manually by adding: $page->logRequests(); to the script file. Visit the page and enable logging (as with any normal PW page) and you're good to go. The only weird thing at the moment with this is that the logged url will be /http404/ but otherwise it works as expected. Let me know if you make use of this approach and if you find any issues. BTW, I still need to add docs for the Request Logger, API Explorer, and Adminer panels to https://adrianbj.github.io/TracyDebugger/ - I've been slack on this. Anyone out there like doing documentation and would like to help ?

Actually, an even better option is probably to use $filePage as this will automatically choose the field from the repeater if the image is uploaded to a repeater image field or the main $page if the image is uploaded to an image field on the main page. Does that make sense?