adrian

Ok, so the problem with the default theme is that the edit links are off by one level, so if you click on the direct parent it doesn't work and if you click on the Home link then you get the child below it. Everything is fine with Reno. I expect the problem is similar to what I experienced when modifying the breadcrumbs with AdminRestrictBranch. Do a quick search for breadcrumb in my commit history: https://github.com/adrianbj/AdminRestrictBranch/commits/master and you'l see some of the things I did to make it work with Reno. Maybe this will help you in the reverse direction to get this working for the default theme. EDIT: Sorry, this is exactly what @Robin S just pointed out!

Update - the editing works with CMD+click with the Reno theme, but not the default theme.

Jeez - make me feel bad why don't you I did think I'd seen something along those lines mentioned, but when I went to try it, it didn't work. I am getting a mix of "popup blocked" by Chrome for the long-click and nothing happening for the CTRL / CMD click. Remember I am on a Mac, so maybe that's the issue?

Hey @tpr - have you considered adding edit links to the breadcrumb trail so that when you are editing a page, you could easily click on one of its parents in the breadcrumb to edit it? Maybe an edit icon after its title, or maybe longclick (although this is becoming synonymous with modal editing which I don't think we want in this case).

From the video demo it looks great, so good job regardless!

But it was in PW weekly https://weekly.pw/issue/131/

Not sure I understand exactly where you need these value to be displayed, but this module may or may not be useful: https://processwire.com/talk/topic/14439-dynamic-description-notes/

Currently no, but would be fairly easy to add. The catch of course is that the CSV you are importing would need the full path / url to each image. Also, if you wanted description and tags, then it would have to make use of the field pairings setup so you could define the subfields, like image.description and image.tags Would this work for you, or were you looking for something else?

Doesn't it only work with debug mode off. Isn't it broken with debug mode on? Or did I misunderstand?

Because with debug mode off PHP notices and warnings aren't reported so they don't corrupt the returned json.

I haven't, but note that the latest version of the Hanna code module doesn't include all those additional files anyway. I would definitely recommend updating and making sure that the main hanna folder is completely replaced, and not merged.

Just a follow up on the issue of Tracy suppressing these notices. I have posted a Github issue here: https://github.com/nette/tracy/issues/233 Note that you will see the actual original error message if you have your browser dev console open, although obviously this is not ideal and I really want it shown in the Errors panel on the AJAX bar in Tracy.

Some more details on Tracy suppressing these errors - turns out (for me at least) that if you have your browser dev console open, you'll get the error from the ajax call output there, which is actually really nice, but I am hoping that the Tracy guys can get this into the Errors panel on the AJAX bar so there is a still an obvious indicator that there is a problem.

I think if turning off debug mode is fixing things then it's a sign that there is an error being returned from the getJson call that you need to debug. Tracy does seem to be suppressing some ajax errors, which is why things work with it on or with debug mode off. I have posted an issue on the core Tracy Github page: https://github.com/nette/tracy/issues/233 - will see what comes of that, but I probably need to do some more testing at my end too.

If you find it easier, this CORS Chrome extension might be useful: https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=en

Hi everyone, I have just added the ability for the PW Info and Console panels to reference the page that is being edited, rather than the Admin > Pages > Edit page (which is generally not a page you'd actually want info about or want to run scripts on). Note, that without this enabled, the screenshots below would be showing the admin edit page with ID: 10. This option is disabled by default to avoid any confusion, but I would recommend that everyone will probably enjoy having this enabled. This idea has been brewing for a little while, but this thread (https://processwire.com/talk/topic/14745-debugging-images/) prompted me to try it out because @microcipcip needed more details about images in the admin because there is no viewable page on the front-end. Please let me know how you find this and if you have any problems!

@Zeka - can you confirm that the settings in the second screenshot are from the Settings tab of the page you selected under "Configurable pages" and not just on the main settings page for BCE? You should be editing the page specific settings like below. As much as AOS's tooltip feature is nice for cleaning up field entry, it has likely prevented you from seeing the notes about this when you selected the Configurable pages.

Sorry, it doesn't seem to be related to AOS at all. It seems to be random at the moment and it just happens that when I initially tested it worked again after disabling AOS. I'll look elsewhere!

Are you talking about the Tracy debugAll() method? When you say it won't show those fields, do you mean the various properties of the images? The output in the PW Info panel is "manually" generated to include all those things. I haven't come across a built in PW method that outputs everything cleanly like that. Take a look at the code I used to generate that array: https://github.com/adrianbj/TracyDebugger/blob/ac3ff2f6cdfcb151d53f7938d3f4ec270f23b115/ProcesswireInfoPanel.inc#L313-L367

Glad it's making sense for you now. Interestingly I have been thinking about having Tracy use the page that is being edited (when editing a page in the admin), rather than the page for the edit process, but not sure if it is really a good idea because it would prevent investigating the actual edit process page if you did want to. Typically in the backend when using d() or bd() in the console panel I do what you did and define $p to the page I am editing, but of course this doesn't help for the info displayed in the PW Info panel. I have made a quick modification to the PW Info panel to support my idea of reporting on the page being edited. I have attached the replacement file for the moment. I'd like to hear how you find it. I'll think on it a little more before incorporating in the released version of Tracy. ProcesswireInfoPanel.inc

Looks like you are viewing this on the backend - you need to view that panel/section when viewing the page on the front-end of the site. Remember that I said getArray(), not toArray()

Not sure when it started happening, but AOS is now removing the "check all" checkboxes at the top of the columns in BCE's edit mode.

Sorry I am not understanding what you are asking here. In the example above we are not parsing the filename. Perhaps you can provide some code showing what you are currently doing.

It's all about checking the $event. Using Tracy, inside your runPatch() method, do this: bd($event); That will return something like: Now that shows that you are looking for: $event->arguments[0] Just to confirm, do: bd($event->arguments[0]); and you'll get: which shows that you can simply do: if($event->arguments[0] === 'MyModuleName') {

@Zeka - it seems to be working fine here - would you mind posting some screenshots of the relevant settings pages and then the appearance (or lack of) the children tab as you would expect. Thanks!