adrian

Hi @MarkE - great point - I haven't come across this, but that's probably because at least in Tracy I have the module itself store page references by path rather than ID. But, I think it would definitely make sense to modify this module to support conversion to paths, but my question is how? I don't think we can realistically check the type of data being stored and know for certain it's a page ID or array of IDs. Sure we could make the assumption that an numbers with 4 or more digits is a page ID and then do a basic check to see if it matches a page. This might be enough, but to make it more robust I think would require parsing the code in the module's files looking for the key in the module settings JSON and determining what type of field it is. I think this could work, but seems a little nuts :) Any thoughts?

Hi @fruid - sorry but I don't know what error you are getting, but also, that line doesn't exist anywhere in my fork, let alone on line 385 :) https://github.com/adrianbj/MarkupSEO/blob/master/MarkupSEO.module

Thanks @szabesz - I did take a look at that and I am hoping that 3.5 years later those 4 devs have now ditched 5.x.

Hi everyone, AdminerEvo was updated yesterday, but the latest version no longer supports PHP 5.x. The fix is simple (it's a null coalescing operator issue), but I am tempted not to push them to support it, but before the opportunity slips by, is there anyone here who really needs 5.x support? I really hope not because if you're stuck on it for some hosting reason, it's time to move :) Let me know.

Maybe still not your thing, but the edit link is now smaller, floated right, and I don't think it takes up any additional space within the inputfield wrapper.

I do the same via admin.less which is nice way to make these sorts of changes - skinning vs a new theme. I did make some quick attempts at a hover approach, but honestly didn't think that took up too much space so didn't persevere too much. I was thinking about a similar approach to the field edit links that AOS adds, but of course the two together get very messy. I'll mull it over and see if I can think of a better solution.

PS I'd love to know whether you have kept the new Adminer field edit links enabled or not - I can see why they might visually annoy some folks, but I am finding them really useful - it's weird how often I actually want to see (and sometimes edit) the raw database value for a field.

I have to admit that I kinda like the standalone mode better as well. I thought I was making things better by being able to include the PW menu, but it is kinda ugly, especially with PW's giant <h1> page titles :) postMessage() is definitely a cool little tool for stuff like this. Maybe if I get enough feedback along these lines, I'll remove it at some point.

Thanks @Robin S for the debugging - both issues should be fixed now. And thanks for the pointer to the Wappalyzer Chrome extension - looks very handy!

Hey @Robin S - I am not surprised about the need for a modules refresh - I have seen the same and honestly not sure what to do about that - seems like one of those situations where PW is holding off updating a module until it is called, but by the time it is called, it's too late and the error has already happened. I am confused by the object in the query string. Could you possibly help by debugging the value of queryStr here: https://github.com/adrianbj/TracyDebugger/blob/c9cb0670f039fb59b1608300b0b12aba322eef45/panels/Adminer/scripts/main.js#L3 and event.data here: https://github.com/adrianbj/TracyDebugger/blob/c9cb0670f039fb59b1608300b0b12aba322eef45/ProcessTracyAdminer.module.php#L37 Thanks.

Hi @Robin S - the latest version has that new "Standalone mode" setting, but I also modified things so that all changes to the query string in the iframed version are now propagated to the parent so if you do want to use the iframed version, you'll now be able to reload the page and it will work as you're used to in standalone mode. I have also added a new option for opening adminer links from Tracy or the page editor - if you hold down "shift" while clicking, they will open in the full version of Adminer (standalone or iframed depending on your settings), rather than in the Adminer panel. Hope that helps, but let me know if you have any other feedback.

Still, I wonder if I should revert the behaviour to the just having the standalone version? Or maybe with a new config setting ("Display standalone") I could have it redirect from /setup/adminer to /setup/adminer-renderer/ - maybe that's the best of both? Any thoughts?

Ah yes OK - sorry about that @Robin S - I thought I was making things better by embedding it within the PW admin so it has the header menu etc. While I think about it, you can for now simply load /setup/adminer-renderer/ instead and you'll get what you're looking for. You can even unhide that page and hide the other one if you want. It's funny really - now that the "Edit in Adminer" links open the panel version, I never use the standalone one at all, but I can understand why you might prefer it still, especially for the query string reloading.

Just a note to say that I've added a new Page Meta section to the Request Info panel. This displays all meta entries for the page, along with links to open the entries for editing directly in Adminer. Speaking of Adminer - it was recently updated to AdminerEvo and I changed the way links from Tracy to open Adminer work - they now open the bar panel version which I believe is a much nicer experience than the standalone Adminer page. I also added links to edit the values of all fields within the Page Edit interface. If the field has multiple values, it will open Adminer showing all entries instead. This is of course optional, so you can visit the Adminer settings (now merged into Tracy's settings) to turn this off if you prefer. Please note that when you first upgrade, you will likely need to do a modules > refresh to get Adminer to load properly the first time.

I am confused by your response - you can write a module to do it if you want, but the problem you had with those errors should now be fixed, so you should be able to use this module now.

Hi @virtualgadjo - sorry about that - should hopefully be fixed in the latest version.

@ottogal - I really don't know - it's not likely an issue with the perms set in config.php, but perhaps the module folders themselves. It might even be the "owner" being off, rather than the permissions, especially if you FTP'd things across initially. Anyway sounds like you have it sorted for now, so let's not worry too much about it.

Really great writeup @artfulrobot You might find that TracyDebugger helps with this to some degree - its "Processwire Logs" panel combines all logs into one ordered reverse chronologically. It also highlights when you have new errors / notices since you last viewed the site.

@Abe Cube - I know this is very old, but perhaps it will help someone else. I just had this same error and it turns out is was due to a mismatched class name and file name. I was testing something and my file was a typo: ProcessHiddenPageText.module.php while the class name was the correct ProcessHiddenPageTest.module.php As soon as I fixed the filename and did a modules refresh, everything worked as expected.

@Denis Schultz - new version of Tracy now uses AdminerEvo. Thanks again for letting me know about this new fork. Hopefully it has a long life. I had to tweak a few things so if anyone see any issues (should be mostly cosmetic hopefully), please let me know.

Hi @ottogal - not sure why that would happen. How did you update Tracy? I suppose you can't really tell anymore, but I wonder if the permissions for that folder were somehow preventing it from being writable by PHP. Anyway, updating is not something individual PW modules have any control over so certainly not an issue with Tracy per se. I shouldn't be related to the PHP version, but you do really need to get that updated - it was EOL'd 5 years ago so you've had no security updates in that time - I would think your host should be more worried about that than an old version of Adminer that was restricted to superuser access anyway - all module files in PW are restricted by htaccess. Thanks for the heads up @Denis Schultz - I hadn't seen that, but I'll definitely take a look and see what it would take to switch.

Tracy has included the updated version of Adminer since it was released almost 3 years ago now, so just update to the latest version and you'll be fine.

That said, I am not running on a multi-site setup so maybe that's the issue. Maybe it's due to a WireHttp call from one site to another? If you share that code, maybe I can test?

I tried that before, but I don't see anything being output in the console which is why I was hoping for a screenshot in case I wasn't understanding where you were seeing the echo'd output.

Sorry, I don't think I am understanding what you are seeing. Can you please post the code that is causing the problem and a screenshot showing the echo'd code in the console?