adrian

You can already do that actually: https://processwire.com/modules/process-admin-actions/#populating-options-via-url-parameters Perhaps you could create a master action that uses a markup field to provide direct links to other actions with the get params in the URL?

Thanks - I understand now. Sounds like a good idea for sure, I'm just not sure the best way to implement at the moment.

Hi @Ivan Gretsky - I don't think I am quite grasping what you are looking for, but certainly happy to consider once I have a proper feel for it. Would it be possible to post some screenshots of the actions that are relevant along with an example explanation of what settings you would like to bookmark? Sounds good to me. I'd certainly like to see more action contributions from the community. There were a couple added to the core AA repo and another by Robin that is maintained as a separate repo, but hooks into AA so that it is available from within it's interface, so there are a couple of different ways to do this.

Hi @Clarity - sorry, I am a bit lost as to what you are asking. Are you referring to a particular action? Is there a place where you are being asked to enter things like 'select', 'text, 'AsmSelect', etc? Maybe post a screenshot of the interface you are finding confusing, or if you are writing a new action, then the list of available field types is only limited to the fields in ProcessWire so that is where you should go for a complete list. Is that what you're looking for?

I am sure it's possible, but as I mentioned, I'd rather avoid the need to add authentication to the module when the current approach seems to be working just fine for normal public video URLs. I feel like there must be some other setting on that video that forces it to only work when embedded. Can you try to make it work without being embedded and see if the module works as expected then?

Maybe you are logged into your Vimeo account? It certainly doesn't show for me:

Maybe there is something I don't understand about certain types of Vimeo links, but take a look at: view-source:https://player.vimeo.com/video/131927792 Note this part of that: "share_url":"https://vimeo.com/131927792" That suggests to me that I should be able to view the video at: https://vimeo.com/131927792 but that link shows "Sorry, we couldn’t find that page", but if I actually let this forum RTE embed the video, it works just fine, eg:

It seems like that video has some restrictions on where it can be viewed. If I try directly at: https://player.vimeo.com/video/131927792 I get a privacy related error, and at https://vimeo.com/131927792 is says it can't find the page. Can you make the video public?

@OllieMackJames - can you provide a link to a vimeo video where this module is currently no longer working. In my testing it still seems OK so I'd like to stick with the current approach if possible because it doesn't require authentication like their new API does.

@d'Hinnisdaël - if you're contemplating moving away from chartjs, can I recommend a library that outputs SVG, rather than canvas - perhaps c3js? The reason being that it makes styling the charts with CSS really easy and also modifying them with D3JS is easy. On a different note, I wonder if you'd consider setting up support for multiple tabs using WireTab? One of my dashboards is getting very long and it would be great to be able to split it up into different views and I think a tabbed interface would be effective.

@kongondo - is there anyway I can easily replicate your setup?

Or maybe the async needs to be in that XMLHttpRequest.prototype.open = function() https://github.com/nette/tracy/blob/a386d3810439f4a72950ed96983b890409c32660/src/Tracy/Bar/assets/bar.js#L475

@kongondo - it sounds like @Rudy is on the right track: https://stackoverflow.com/a/27046133/1524576 This comment on the same thread: https://stackoverflow.com/a/28478146/1524576 is also worth a read. The question I have though is which script is being load synchronously (and shouldn't). Is it perhaps fixable by putting async in the script tag on this line: https://github.com/nette/tracy/blob/da8677c87e4ed645523ea91e0b6cf1d595e60fe1/src/Tracy/Bar/assets/loader.phtml#L22 Maybe you could test that to see if it fixes things for you?

@lpa - typically bd() calls work fine in modules, but there a few reasons why the normal dumps panel may not work (I don't know specifically why it's not working with Padloper), which is one of the reasons why I built the "recorder" version to capture those. Also it is useful to compare dumps across multiple requests.

Thanks - still not sure how there ended up being arrays for the title, but maybe this was from an old version and you haven't cleaned up in a long time? The cache is in /site/assets/cache/TracyDebugger/dumps.json so you can delete that file. Keep in mind that in general you should use the "Clear Dumps" button within the panel itself when it is working again. Also, this is not a panel that you most likely want to leave on all the time and you should clear the dumps after your current debug needs.

Thanks @lpa - that definitely helps. So now we can go back to line 24 of /site/modules/TracyDebugger/panels/DumpsRecorderPanel.php - for some reason $item['title'] is an array. Could you please place bd($items); between line 15 and 16 of that file and post a screenshot on the resulting dump (fully expanded). It should look something like this: except that those title keys will have an array as the value. Maybe by seeing what they are, we'll be able to figure out why it's happening in the first place.

Hi @lpa - I am not sure exactly, but it would be helpful if you could find out the value of $s on that line to figure out why it's an array instead of something that can be cast to a string. Also, are you trying to bd() anything in particular, or does the error show as soon as you load the panel?

@julianmark - good luck with getting the FTP login details. I do think that's a little unfair of a statement to make given that you also state: :)

The reason you are having issues with this module install is not because of the module itself, but because you likely recently updated to the new master version of PW that implemented this new requirement for installing modules via the admin. I am beginning to think that you didn't create this site yourself, but inherited it from another developer? If you don't have access to the filesystem (think about the files / folder you see when using Finder on a Mac or Explorer on Windows) you might have some problems. If the site has TracyDebugger installed you can edit the config.php file via the admin with the FilesEditor panel, but otherwise you will need to get access to the filesystem via SSH or (S)FTP. Can you get access to those?

The config.php file is in the filesystem at /site/config.php Depending on your server setup, it might be at: /var/www/html/site/config.php But if you have already built template files, you'll be used to where /site/templates/ is :)

@julianmark - https://processwire.com/modules/page-protector/

@ryan - I am still getting a decent amount of spam coming through, even with both types of honeypot fields and akismet enabled. Presumably these are person written spam (rather than bots). I think it would be great if there was a way to hook into checkNewComment() (or similar) so we could add our own checking. In my case, I'd probably like to add Mailgun's email address validation. Thanks.

The easiest fix is to change "count" to "wireCount"

Sorry to hear about these issues - I'm not really sure what to suggest at the moment. If you see them again, could you possibly dig a little deeper to see if there is something in Tracy that needs fixing?

Thanks for your research and thoughts @Robin S - much appreciated as always, but I wonder about the "near miss" you are suggesting. Given that files under /site/modules/ can't be executed directly and I have Adminer locked down to superusers only, I am wondering how that version with the vulnerability could have been exploited within a PW system? I know that nothing is ever completely secure, but wouldn't it take someone with filesystem access to be able to do any damage in this case, and if they have that, then there are lots of other ways they could do damage anyway. Am I missing something? I'm definitely happy to hear more arguments for (or just more folks in favor of) separating it into its own module.