bernhard

Sorry, but this does not do anything ? $data = '"{\"code\":\"xxx\"}"'; return "<style> #tracy-debug-panel-ConsolePanel { left: 0 !important; top: 0 !important; width: 100vw !important; height: 100vh !important; } </style> <script> // open the console automatically localStorage.setItem('tracy-debug-panel-ConsolePanel', $data); </script>"; The panel opens, but the code does not change...

I didn't want to ask ? Ok where do I find such an example? (I tried searching for tracy-debug-panel-ConsolePanel in my project but didn't find a good result..)

v0.0.6 is out and adds support for dumping RockFinder to the tracy console. Important: This dumping feature does only work when you are on the tracy process module of RockFinder: PS: RockFinder3 is in the works ?

Wow, this is brilliant ? That worked perfectly, thanks! ? Same here ? I think we'd need to collect some example use cases and then decide what could make sense. Pushed everything to RockFinder2 master branch ? So I can get rid of lots of bloat in RockFinder3 ?

Sounds interesting. Which hoster are you using? Links to the api please ?

I think that would have the same effect of breaking frontend editing modals. But you can easily allow modals via checking if $input->get->modal == true (note double == not triple, because modal can be 1 or panel or modal)

Hi adrian, this is great, thank you!! ? I got it working here ? You can try it using RockFinder2 "tracy" branch: https://github.com/BernhardBaumrock/RockFinder2/commit/4b78566ecc87d2af0e5b33b721cbad27912ddb8f So you see that I've created a very simple process module that loads tabulator and does a css override to make the console fullscreen. Simple and perfect solution. Only thing missing is a feature to open the console panel automatically when the page loads. Somehow I didn't get that working using jQuery's load event and triggering a click on the panel item. How could that be done? PS: I wonder if that tabulator feature could be useful not only for RockFinder but in many other cases, like dumping the result of an SQL query for example. Using RockFinder this is already possible (because RockFinder can take an sql query as source), but I wonder if it could make sense to ship such a tabulator feature with tracy by default? Just not sure how to check if tabulator is already loaded (eg via my module)?

I think so, yes. But it should be quite easy to whitelist some pages/templates/roles and only redirect all other requests ?

Just had another idea that might be even more powerful and simpler to implement: What if we could define custom dumping functions? For example: $rf = new RockFinder2(); [...] tabulator($rf); // modify tabulator and dump another one tabulator($rf); instead of a regular dump() this would render the markup of a tabulator, eg: <div id="1905terf8dvuid"></div> <script> var table = new Tabulator("#1905terf8dvuid", { 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> So basically we'd only need a way to define custom functions like "tabulator()" that define the returned markup and that's it ?

Actually this would also prevent you from opening the login-screen. But you get the idea and can modify it to your needs (like checking for a user role or a page template or id etc.).

I think it should be enough to put this in your /site/templates/admin.php if(!$user->isSuperuser()) $session->redirect('/');

Thx adrian, this is what I have currently in my RockFinder2 module: This is basically a sandbox where one can test finders, sees a dump and also sees the data listed as tabulator. When looking at the code of RockFinder2 today I was quite surprised that it has +1200 lines of code. I had in my mind that it is quite lightweight compared to RockFinder1 because it builds upon the pw core query classes. Then I realized that I actually have lots of stuff packed into RockFinder2 that imho does not belong there. The finder tester is one of those things! I want to remove that part from the module so that RockFinder3 will just do one thing: Finding PW data and returning it as array of objects. Nevertheless the finder tester is useful! So I don't really want to drop it as a whole. I can use the tracy console and do this: This is already great, but it would be even greater if I could see the data in a tabulator. That's what I have in my process module, BUT: What I do not have there is the dumping features of the tracy console. Look at the first screenshot: There is a dump, but I always dump the returned finder object. I cant to any other dumps, because it's a custom implementation of the console. I also don't have the same settings and shortcuts as in the console. Vision: Ideally I'd like to build RockFinder3 with only the features that it needs and pack the tester in a separate module. This module would require tracy (but only the process module, not the finder module) and could use the tracy console process. This process would show an InputfieldForm that everybody could modify easily via hooks. So I could just add a new InputfieldMarkup to that form below the tracy console, add some lines of javascript that intercept the AJAX events sent by the console and then show the result as tabulator grid. Hm. I see that the ajax response at the moment does only send the html of the dumps. Maybe it could instead send the response as JSON? One property being the dump: "<foo>bar</foo>" and the other property being the returned value: In this case the code would return a RockFinder2 instance, so we would need something on the backend that transforms the returned data (here the rockfinder) in something readable by the client. Maybe something like this: // pseudo code $wire->addHookAfter("Console::getPayload", function($event) { $rockfinder = $event->arguments(0); $array = $rockfinder->toPlainArrayReadyForJavaScript(); // ['foo', 'bar'] $event->return = $array; }); This would result in this ajax response: { dump: "<foo>bar</foo>", return: ['foo', 'bar'] } So the console could just dump the markup and I could intercept that response with JS: $(document).on('tracyConsoleResponse', function() { // get the return value of the xhr // render tabulator }); Maybe that kind of refactoring could also make sense for the console? Maybe this approach could also make sense in an even bigger context: What if all panels where process modules? I for example have no idea how to build a panel for tracy (I'd have to study my hello world module again ? ), but it would be piece of cake to build a process module. Maybe I'm requesting too much here. But again: Maybe refactoring could make sense - I leave that assessment to you ? --- Side note: Also I have this bug when I open the console on my process module: The code of my ACE field gets quirky. That's not a request how to fix it - just to let you know why it would be great to have one central solution that can be modified instead of building our own solution and fix bugs ?

Hey @adrian, would it somehow be possible to get the tracy console in a separate process module? I'm working on my RockFinder and there I have built a "RockFinderTester" process module that does basically the same thing like the tracy console, only a lot worse ? I have many modules where a console feature would be great for testing. At the moment I'm using the console for lots of things, but I wonder how complicated it would be to move the console to a separate page that we can modify to our needs. So for example for testing a RockFinder it might be great to have the code input on the top and below that it would be great to have an area where I can not only dump variables but also show the result as paginated table (using tabulator.js). The tabulator part could totally be done by me - I'd only need to have the proper JS events I can listen for. I know we have the console snippets at the moment, but I think the console is such a powerful tool, that it would be great if it could be used by other modules as well. Do you understand my idea? Would that be very complicated to achieve? Thanks in advance for thinking about it ?

You need to init() the panels again. This is usually done when the dom is first loaded. So panel-links don't work on ajax loaded markup. See this request + workaround: https://github.com/processwire/processwire-requests/issues/176

I think I have never ever used any of the recipes - if anybody uses that as source of such snippets feel free to post it there. My screenshot is licensed under MIT ?

$format = $modules->get("TextformatterMarkdownExtra"); $format->format($str); echo $str;

Would be great to hear your experience then. Is @LostKobrakai's module really obsolete or does it still have its place?

Personally I don't care, because I'm using my version only (of course). But for someone new to migrations and having to decide between the two options your points might be a good reason to choose RockMigrations. So for them it might be good to know, yes ?

Just pulled a PR from @Craig, updated the readme, bumped version to 0.0.8, removed the beta flag and submitted the module to the modules directory ? I'm using this module now on all my projects and I'm happy to get some feedback if anybody else is using it. Stars/Donations welcome: https://github.com/BernhardBaumrock/RockMigrations/stargazers THX

v0.0.5 adds column alias support for @David Karich s options field shortcut and adds another one to get the title instead of the options value: Showing the title/value of selected options instead of ID values Options fields store 3 things in the database: The ID of the option, the value of the option and the title (for each language) of the option: There are two custom column types to get the value or the title of a selected options field:

Would be nice if you could try RockFinder2 and share your results ?

I don't understand this part. Doesn't that mean you could replace the lister bookmarks by a process module showing a RockTabulator and this RockTabulator would show data based on the 2 get-parameters? eg /your-admin/financials/?income=2015&cash=2018 This would mean unlimited number of RockTabulators with just one process module instead of one lister per income/cash combination?

Yes, perfect use case for it! RockGrid still works, but I'll not develop it further. I switched to tabulator.info some time ago, because ag-grid (used by RockGrid) is not fully open source and quite expensive if you need excel-export for example. I have to note that I want to rebuild RockTabulator soon, but not sure when I can manage to do that. If anybody has a project that could benefit from such listings and would be willing to outsource the work and sponsor the development of a new (and well documented) RockTabulator write me a message ? PS: If you want to keep things simple, you could even use your own implementation of tabulator.info or ag-grid. RockFinder2 will do the "hard" work of getting the data and you can simply display that data in a nice way with those js libraries. If you don't need any editing stuff, this should be really quick and easy!

Yep. Perfect solution ?

Doesn't that need to generate the md5 hash of the file on every request (if not cached)? I guess filemtime() is a lot faster than md5_file()?