adrian

Well it took several hours of discussions with @bernhard and lots of back and forwards on the best way to do things, but we've finally committed the "WebHooks" panel he posted about above. It's now called the Request Logger panel because in reality it is logging requests to a page on your site - who knows whether it's really a "webhook" request or something else. Instructions 1) In the PW admin, edit the page you want to log incoming requests for. 2) Open the Request Logger panel. 3) Click the "Enable logging on this page" button. 4) Send a request to that page. This may be something like a confirmation of payment webhook call from Paypal etc. 5) Reload the edit page in the PW admin to see the logged request. The reason we say to edit the page, rather than visit it on the frontend is because visiting the page would result in a logged request. Note that you can easily test incoming requests using the Postman app (https://www.getpostman.com/). You can choose POST or GET and under "Body" you'll want to specify Raw / JSON You'll notice the json supplied in the Postman Body is what shows up in the Request Logger panel under "input" and "inputParsed". This is all well and good, but here's where the magic really comes in ? There is a new getRequestData() method added to $page so you can get the logged data in your code. You can get logged requests by: ID (shown in the title of the logged entry in the Request Logger panel) ALL requests (an array of all logged requests for the page) The last logged request by passing "true" The current live request This allows you to have access to the data sent by the webhook without constantly having to trigger it each time - ie no need to continually make test payments over and over as you refine and debug the your scripts that consume/parse this data! You can even make use of $page->getRequestData() in your final live code if you want - this does not rely on Tracy being enabled - it just has to be installed. So you could potentially execute one request and then use the "true" option while testing, and then when you're ready to go live, you can remove the "true" so it returns the live request. There is a config setting to determine whether this method returns an array or an object. Please take it for a test drive and let us know what you think! @bernhard - did I miss anything worth mentioning?

I am sure support could be added for this. Any chance you feel like having a go at implementing it? Sorry I am juggling lots of different commitments right now, but I'll take a look when I can if you don't get to it first ?

I use curly braces, like this: {$page->title}-[Y_m_d_H_i_s]

You should be able to specify any PHP date() format you want - if you want to replace those dashes with underscores you can. I think that should take care of the conflict with the "-n" suffix check.

Does this help: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#page-gt-references

Sorry about the issue with the unknown module error. I'll fix that in the next commit. Keep in mind that if you don't want it to appear under the Setup menu, you just need to make Admin > Setup > Adminer hidden. That way you could still use the Adminer panel from the Tracy debug bar. Does that help? Also, I know it's obvious, but only superusers will see the Setup > Adminer option.

I am not certainly exactly what isis.pw uses, but I think it looks for things like a response from ?it and /assets/files paths to images. Maybe also ProcessWire in the header. Hopefully teppo will chime in.

Hey @Guy Verville - great writeup and a great looking site! This is a question for both you and @teppo - I am wondering what is unusual about your site that is causing isit.pw to not be able to detect it as a PW site? Or maybe isit.pw is caching an old lookup for your site?

Hey @bernhard - this looks really fantastic - thank you! I have a few comments re code styling to match the rest of Tracy, but I can clean that up after accepting the PR. What I am wondering is if it might be useful to add a $page->getWebHookData() method so that you don't need to know the ID of the hook. Obviously the data that is stored would need to include a pageid (I see you already store that) so this new method could grab an array of objects just for this page. I think it would also be great to be able to do: $page->getWebHookData()->last() to get the last one. Not sure how useful first() and eq() would be in this case. Maybe eq() could be in reverse order so you could get eq(0) as the last received, eq(1) as second last, etc - what do you think? I'll take a better look tomorrow and do some testing, but really excited to start using this!

Thanks for the debugging. That actually makes sense because I have a check to not rename files with "-n" extensions because PW's automatic adding of "-n" when there is already a file of the same name. I'll have to see if I can sort out a workaround for this, but I won't be able to look until tomorrow.

Couldn't CustumUploadNames be modified to handle this need?

Strange - it seems to be working here. Is there something in your setup that differs from this?

Not really sure that could be dealt with without maintaining a database of filename changes and associated page ids and checking against them whenever a page is changed. If you have a simple approach I am not thinking of, I'd be happy to implement.

Good point. I am attaching a new version here for you to test. I don't have much time this morning to test it properly, but hopefully this will also handle that. @simonsays - could also please test this version? ProcessCustomUploadNames.zip

Thanks @Robin S - I see that adding the tabbed interface was a significant amount of work - I think it's awesome though so thank you ? One small thing - it needs a fallback to tab_name if there is no label set. This should be an unlikely scenario, but without it, you can't get to the other tabs. $markup .= "<li class='tfw-tab{$active}' data-tab='tfw-{$tab_name}'>" . ($tab_data['label'] ?: $tab_name) . "</li>";

@PWaddict - it should now work in the latest version. @simonsays - I think all your repeater issues should also now be fixed - sorry again for the huge delay on this.

Oh sorry, I missed that distinction. I'll see what I can do about supporting that situation.

Are you in a repeater or anything else unusual?

Any chance you are inserting into a multi-language textarea field? If so, then it should be fixed in the latest version. If not, please let me know and I can investigate further.

Of course - sorry, I didn't realize that was a goal. I guess I thought it would be ok to use the mouse to activate the other tab. Perhaps an alternative would be to just separate out other tabs below the main Content tab so they are separate. I just think this would help with visualizing the layout better, because at the moment it looks like the fields in other tabs are all part of the one form, which of course they are not, visually speaking. Anyway, not a big deal ?

Tabbing works find in the PW admin when editing a page - you can use the tab key to move between fields in any of the WireTabs - Content, Custom tabs, Settings, etc. Maybe I am not understanding the issue you are referring though ?

New links from the Debug Mode panel's "Cache" section to edit it in Adminer: Adminer DB icon links to where you can easily review the cache content, edit, change the expires datetime, or delete it. Also note that Adminer now has @bernhard's request for a PW icon link back to the site's PW admin backend. Let me know if you guys have any suggestions for other direct links to Adminer - I am finding these very handy.

Sorry, I haven't forgotten - just had other priorities get in the way - I'll try to take a look soon.

@lenoir - I think all those old themes should be removed from the modules directory - hopefully with the imminent site rebuild they will be. I think the problem with PW's admin theming approach is that new functionality doesn't make it into 3rd party themes. I have always said that we need a skinning approach, rather than (or perhaps in addition to) theming. That said, the approach that AdminThemeBoss takes is in effect a skin, rather than a separate theme and I think this is great and is perhaps a model for others to follow.

@ryan - this issue still exists on 3.0.119 - any chance of a fix please?