adrian

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!

This is a start for you that comes from the Migrator module: $p = $pages->get() // use this to get the page that you are importing comments to foreach($comments as $comment){ $c = new Comment(); $p->of(false); $c->text = $comment['text']; $c->cite = $comment['cite']; $c->email = $comment['email']; $c->ip = $comment['ip']; $c->website = $comment['website']; $p->fieldname->add($c); $p->save(); // setting the status doesn't current work due to this: https://github.com/ryancramerdesign/ProcessWire/issues/1034 $c->status = $comment->status ? $comment->status : 0; //need to set after saving to allow setting status without being subject to moderation settings $p->save(); } This assumes that you have already parsed the rows of the CSV file into the $comments array. To do that, take a look at: http://php.net/manual/en/function.str-getcsv.php Hope that helps to get you going.

Then again, if you have Tracy, then look at the PW Info panel and the "Field List & Values" section and you'll get a nicely formatted array, like this:

Try this with Tracy: bd($page->images->getArray());

Perhaps the best thing to do at this point is find the three entries in the field_title, field_process, and pages tables and replace or add them. Just so you know, this is where the Process can be selected: It can't be chosen when creating the page, can be assigned once it is saved the first time.

Can we assume that everything is now working after recreating the module page?

Yeah, sorry, that should probably have been my first suggestion When you recreate it, make sure you choose "ProcessModule" as the Process on the Content tab under title. Actually I wonder if the better way might be to run these three commands to make sure page ID is correct - I am not sure if that matters or not. INSERT INTO `field_title` (`pages_id`, `data`) VALUES('21', 'Modules'); INSERT INTO `pages` (`id`, `parent_id`, `templates_id`, `name`, `status`, `modified`, `modified_users_id`, `created`, `created_users_id`, `sort`) VALUES('21', '2', '2', 'module', '21', NOW(), '41', NOW(), '2', '2'); INSERT INTO `field_process` (`pages_id`, `data`) VALUES('21', '50');

The flags aren't quite that simple - they are more than just on/off - 0/1. I'd like to know more about what you actually see when you try to visit the modules page directly when you have debug mode on. Is it a blank page? Also, what about showing us what is under the Admin branch in the tree:

Sorry - I misread your last post completely. I am running out of ideas - any chance this site is live and I could take a look?

Ok, so if the modules db table is missing that sounds like the problem. If you don't have a backup, I would suggest the best option might be to grab the appropriate section from the install.sql file, eg https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/site-default/install/install.sql#L271-L368 and paste that into the SQL tab in PHPMyAdmin or some other tool.

Do I understand correctly that this happened after installing a new module? Can you remove all its files from site/modules/ and also its line from the modules database table.

Did you try the refresh I suggested? What about logging out and back in again? What about emptying site/assets/cache/FileCompiler?

Can you view the modules page via its URL, eg. mysite.com/processwire/module/ Just trying to figure out if it's just the menu that isn't working. I'd also try calling Modules > Refresh directly, like: mysite.com/processwire/module/?reset=1

Do you have debug mode on? Might be some errors.

Silly question perhaps, but are you logged in as a superuser? Just an FYI - it is possible, depending on permissions, for a user to be able to see the Setup and Access menus, but not the Modules menu.