adrian

Remember you have some wording in the docs that needs changing, eg "The ProcessModule of RockFinder3 does use Tracy for dumping the results, so TracyDebugger is required for the ProcessModule to run."

Assume you have read these: https://github.com/ryancramerdesign/ProcessWire/issues/710 https://github.com/ryancramerdesign/ProcessWire/issues/1757 He says that "whitespace is preferred in many cases", but I just don't get it - not sure how trailing whitespace has any advantage, but maybe I am missing something ?

Sorry you find it ugly - I know it doesn't look nice, but it's one of my favorite things in Tracy - so nice to know which browser tab has the dev version vs live version of a site.

Just have VSCode set up to automatically remove trailing spaces at the end of lines. It's a pet peeve of mine and something I wish Ryan would do with the PW core. Nothing new - it's just a shame that we can no longer see the values in query - makes it impossible to easily copy / paste a query into Adminer etc to test directly. Are you going to completely remove the Process module now? Does it serve some other purpose?

@bernhard - test out the attached version which avoids the need for the Process module by loading the tabulator files on demand. RockFinder3.module.php

@bernhard - you might be interested in this: https://github.com/processwire/processwire-issues/issues/1173#issuecomment-632868896 and Ryan's reply. Once you upgrade to the latest PW dev and use your dumpSQL() method you'll see what I mean ?

I might give the FA icons a go. The reason I didn't initially is because they aren't loaded on the frontend of a site, but these days I do load them with Tracy for the custom links in the PW Info panel anyway, so it wouldn't be any extra load now, although I think someone mentioned they were having issues because they were using FA 5 on the frontend and there was some conflict. I'll think about it later.

That fixed it - thanks!

Hey - teamwork makes the dream work ? Totally OT, but damn I hate the look of that plus (New Snippet) icon in the console on Windows - sorry it's so ugly - I need to swap those all out for SVGs at some point.

Well, it's not just the "created" field - the same error shows with the "name" field as well. Loving some of the options this has BTW - having those docs has really shown me what this can do! Just a thought about the Process module and the Tracy Console - I am not sure it's clear that the Process module is only needed to load Tabulator - otherwise loading the Console panel from any other page works for dumping the objects in the normal Tracy way. I do think it would be great to figure out a way to load the Tablulator script on demand in Tracy if a RF dump() is called.

Hey @bernhard - looking awesome - I think it's time I took this for a proper test spin ? Just tested my first query and got this error:

Keep in mind though - this may annoy some users because it will overwrite what they already have in the Console. Another thing I am wondering - why have a separate Process module for this - couldn't the required code be loaded by the main RF module so that users could do a $f->dump() on any page?

The localStorage key for this is "tracyConsole"

Look at the LocalStorage section in your browser dev console:

Also, you might want to prepopulate the console panel by adding another localStorage entry for "tracyConsole" - take a look at an existing entry to see the required format.

Great @bernhard - can you please try without the \TD::echo() method like in my second example above - just echo directly in your new dump() method. I made the change to the Tracy branch of your module and it worked fine - no need for that method as I noted in my second post above. The easiest way to open the Console panel automatically is to add this to the "return" of your executeConsole() method. <script> localStorage.setItem("tracy-debug-panel-ConsolePanel", "{}"); </script> Typically there would be width, height etc elements in there, but you are overriding these with CSS anywhere, so the empty {} is all that's needed. As for including tabulator in Tracy - I really like the idea but I am not yet sure how best to make it so it's easy to have data in the correct format for tabulator to work with - mostly issues with the column headings vs the data rows. Any thoughts?

Actually, you don't even need the new TD::echo method. All your tabulator() method needs to do, is echo that HTML directly: function tabulator($str) { echo '<div id="tabletest"></div> <script> var table = new Tabulator("#tabletest", { height:205, data:[ {id:1, name:"Oli Bob", age:"12", col:"red", dob:""}, {id:2, name:"Mary May", age:"1", col:"blue", dob:"14/05/1982"}, {id:3, name:"Christine Lobowski", age:"42", col:"green", dob:"22/05/1982"}, {id:4, name:"Brendon Philips", age:"125", col:"orange", dob:"01/08/1980"}, {id:5, name:"Margret Marmajuke", age:"16", col:"yellow", dob:"31/01/1999"}, ], layout:"fitColumns", //fit columns to width of table (optional) columns:[ //Define Table Columns {title:"Name", field:"name", width:150}, {title:"Age", field:"age", hozAlign:"left", formatter:"progress"}, {title:"Favourite Color", field:"col"}, {title:"Date Of Birth", field:"dob", sorter:"date", hozAlign:"center"}, ], rowClick:function(e, row){ //trigger an alert message when the row is clicked alert("Row " + row.getData().id + " Clicked!!!!"); }, }); </script>'; } The only thing it misses this way is the helper for displaying the title bar at the top of each output, but all that really is, is <h2>title</h2> anyway, so easy to implement directly if you want. What do you think? Any need for the TD::echo() method at all?

@bernhard Just a little rough experimentation - I've added a new echo() method to the TD class which outputs exactly what is sent to it. With this addition, I managed to do this: Obviously in this case I am not passing any data to the tabulator() method, but you can make this happen easily by modifying your new tabulator() function. In a process module I have a couple of things to make this all work: 1) Load the tabulator js and css files in the init() method: $this->wire('config')->scripts->add("https://unpkg.com/tabulator-tables@4.6.3/dist/js/tabulator.min.js"); $this->wire('config')->styles->add("https://unpkg.com/tabulator-tables@4.6.3/dist/css/tabulator.min.css"); 2) Define a new tabulator function - note that in this case this is a global function outside the process module class, but you could also make it a class function and call $rf->tabulator() function tabulator($str, $title = NULL) { \TD::echo('<div id="tabletest"></div> <script> var table = new Tabulator("#tabletest", { height:205, data:[ {id:1, name:"Oli Bob", age:"12", col:"red", dob:""}, {id:2, name:"Mary May", age:"1", col:"blue", dob:"14/05/1982"}, {id:3, name:"Christine Lobowski", age:"42", col:"green", dob:"22/05/1982"}, {id:4, name:"Brendon Philips", age:"125", col:"orange", dob:"01/08/1980"}, {id:5, name:"Margret Marmajuke", age:"16", col:"yellow", dob:"31/01/1999"}, ], layout:"fitColumns", //fit columns to width of table (optional) columns:[ //Define Table Columns {title:"Name", field:"name", width:150}, {title:"Age", field:"age", hozAlign:"left", formatter:"progress"}, {title:"Favourite Color", field:"col"}, {title:"Date Of Birth", field:"dob", sorter:"date", hozAlign:"center"}, ], rowClick:function(e, row){ //trigger an alert message when the row is clicked alert("Row " + row.getData().id + " Clicked!!!!"); }, }); </script>', $title); } You can try it out by replacing the attached TD.php for your Tracy install (in the includes subfolder). Note that you can supply two arguments to the \TD::echo method: $str and $title, just like with d() and bd() Does that work for you ok? TD.php

@bernhard - I like you're thinking here. Surely it would be a simply matter of extending Tracy's TD class (https://github.com/adrianbj/TracyDebugger/blob/master/includes/TD.php) with the required new dumping methods.

I actually found that quite buggy still and IIRC it doesn't handle RTE embedded images (ie it doesn't rewrite their paths to the new location) like Migrator does. Not saying Migrator is perfect by any means, but the core page export/import was pretty broken in my experience.

Check the import settings where is says "APPEND will not change settings of existing fields, nor the content of existing pages."

Hey @bernhard - thanks for all the details. I'll have to get back to you on most of them, but I can explain the reason for the quirky stuff in your module. It is due to the really old version of ACE included with the InputfieldAceExtended module that you are making use of. The same thing happens with Ryan's HannaCode module - there is an issue posted about that here: https://github.com/ryancramerdesign/ProcessHannaCode/issues/21

@Peter Falkenberg Brown - sorry, I don't understand why you are trying to reinvent the wheel here - there are a LOT of problems to solve and Migrator works for this already.

I have thought about making it a separate Process module so it can be opened on it's own page in the PW admin, but I am not sure about making it modifiable - what would you need to modify for you needs? Based on your tabulator example, it sounds like you are talking about extending the output options? But how best to do that? Is it just a matter of being able to inject (in the background) some additional JS to process the code and format as a table? I am happy to talk about this more, but I haven't enough time at the moment to do anything substantial on this unfortunately. If you could think through how it should work in some more detail, that might make make it easier for me to implement. Of course PRs are also welcome, but I am happy to help implement if you figure out a plan for how it should work.

@Peter Falkenberg Brown - I still use https://github.com/adrianbj/ProcessMigrator for things like this - it works a treat with images (including updating paths to RTE embedded images). It's not regularly maintained and some users have had issues over the years but I still find it much more reliable than the PW core export/import tools.