adrian

Based on the comments above it sounds like there are currently still some issues with 3.x. @kongondo is away at the moment, but I am sure he'll be looking at getting this 3.x compatible now that we are so close to a stable release.

I was waiting for your response here - sorry about that - no offense intended

It's certainly no big deal at all

In most cases you can simply do: if($page->template == "admin") { but this needs to be in ready(). If you need it to work within init(), then I use: if(strpos($_SERVER['REQUEST_URI'], wire('config')->urls->admin) === 0) {

I didn't add it - it's the details of the selector. Not sure, but I think maybe this only appears with ListerPro.

Minor css issue - notice the location of the notes icon - this is the iframe that contains the Usage details on a template settings page.

@tpr - the latest commit fixes the "Uncaught Error: Class 'Tracy\Debugger' not found" error in modals. I have also changed the behavior slightly. Tracy is now loaded in normal modals, but not inline ones. I think this is a good balance, but let me know if anyone has any strong thoughts on this. FYI - an example of an inline modal is the "Usage" section of a template settings page.

Thanks - sounds like that is probably the case - will see if Ryan can help get Tracy loaded first all the time. Actually I intentionally prevent Tracy from loading in modals although I do see why the last commit has changed when you get that error. I can easily have it loaded for modals again though. I was disabling because I thought it was superfluous and looked ugly, but maybe it's important, especially if the modal contains an iframe - in that case having Tracy enabled would be the only way to debug the content of the iframe.

Mostly yes - I expect the issue you are having is due to the module you are testing being autoloaded before Tracy. I have raised an issue with Ryan to try to get the ability to specify load order priority. However, just to be sure could you also test in the init() of some other autoload modules. It worked for the ones I tested and it sounds like it is also working for @Mike Rockett - so I do think it's a random load order issue, but would be good to confirm. I will do - we don't currently have a 2.8 option in the modules directory.

Not meaning to hijack for promoting TracyDebugger, but if you grab the very latest version from today, it will let you do bd($this->renderAssets()); or: bd($out); to dump as @Robin S suggested. Prior to the latest version of Tracy, bd() calls in PW files often didn't work because of the order of when Tracy was loaded. Hope that helps a little!

Ok, I have tested further and can't find any problems, so I have committed those changes. You should now be able to use debug statements before page ready which should help significantly with module development. Please let me know how this works for everyone and also if you notice any problems elsewhere in Tracy as a result of these changes.

@Mike Rockett - I decided to do some testing here and I think I have a working version for you. There was a lot of code reordering to make this work (needed to put lots into init(), so I need to test some more to make sure I haven't broken anything in the process, so won't push live just yet, but I'll PM you a copy of the version I am testing - would be great to know if it works for you too.

This looks great @horst - just one initial request - can we lose the "Wow that looks great" button label and make it simply "Continue" or "Accept" or something similar. And maybe the "Not happy, crop again" link should be a button with "Redo Crop" ? PS I know these labels are a legacy of the original thumbnails module, but they do sound a little weird to me.

Great - thanks - and please leave the bd() or TD::barDump call in the spot where you are trying to use it. I have also just reminded Ryan about a request I made some time ago for making it possible to specify load order priority for autoload modules, which might also be relevant to what you are seeing.

So does Tracy work with JL1 in the same place? I think it's because you are making the bd (or whatever variant) at a time before Tracy is loaded because everything is loded in ready(), not init() - this is because I need info that isn't available until ready(), but maybe there is something I can do as a workaround?

Hi @Mike Rockett - firstly, the bd() and other shortcuts should be available from the global namespace, so I don't think there should be a need to call \TD:barDump() but maybe I am missing something there. Now to that Class TD not found error - my initial thought is that maybe you are calling it from inside the init() method in your module, rather than after ready() ? Or perhaps your module is simply being auto-loaded before Tracy. Any chance I you could PM me a copy of jumplinks 2 so I can see if I can fix this?

The error is saying that the function is available, but what it is being called on is not - ie $homepage So you can either define $homepage like: $homepage = $pages->get("/"); or you can do: $hreflang = $pages->get("/")->getLanguageValue($language, 'name'); if you don't need $homepage anywhere else.

A wild and unlikely guess, but any chance it has something to do with the case of your class name and your php version? What if you try: TextformatterListCk Note the lowercase "k"

The ID field of the pages, templates, and fields database tables has AUTO_INCREMENT applied to them, so I unless you manually adjusted that, I think there should be no chance of reuse. I don't think PW has any specific checks, but the database itself should make sure there is no reuse unless you mess with things.

What about from the modules directory: http://modules.processwire.com/modules/czech/

Working fine here so I would try uninstalling and reinstalling. Is it now being loaded at least and just not formatting, or is it not even showing up as loaded by Tracy? Stupid question I know, but after all your testing, do you now definitely have it applied to the desired field?

I think the problem is one of these: 'autoload' => false, 'singular' => false, 'permanent' => false, Just remove all those and refresh and it should work - at least it does here.

In a rush, but when I install your module the flag field in the module's database table is set to 0. If you change that to 1 and do a modules refresh then Tracy shows it as loaded.

Working on this module is starting to become a full time job! Unfortunately I don't think it's a simple as that for some modules - for example you can't simply disable a fieldtype without wreaking havoc. I still think this panel is useful - I am just hoping Ryan can sort out that issue which I think is related to just those modules using a separate config file (like ProcesswireUpgradeCheck). This has just been implemented in the latest version. This is Just a first attempt - any variable that is only used once is highlighted with the orange warning color. Other significant changes in the latest version. Fixed a problem with the Validator plugin that was introduced 4 days ago by a new requirement (the user_agent needs to be supplied in the post request) from validator.nu (https://github.com/validator/validator/commit/a6afb4f34402bce421df5102de313ec76295a55f#diff-5f739a043bdc345584b06cb39a7679aaR259) Make it easy to pass maxDepth and maxLength options to bd() calls. This can be very handy when you have a deep array or very long string that you need to see more of without changing the defaults of maxDepth:3 and MaxLength:150 which can cause problems with PW objects if you go too high. bd($myArr, 'My Array', array('maxDepth' => 7, 'maxLength' => 0)); Note that setting to '0' means no limit. I also I just wanted to note how useful the "Preserve Dumps" checkbox in the Dumps Recorder panel is - lots of times when doing module development in particular I found that bd() calls weren't showing up - I think it often has to do with the redirects or the call being made before the panel is ready or something. Now with this feature, even if it doesn't show initially, just reload the page and it will be there!

Yeah, it can be a real PITA. I am not too worried at the moment as the functionality requires PW's advanced mode and I am hoping Ryan might have some solution to that issue I posted. This panel is not adding new functionality - it's really just making it easier to disable lots of modules at once / in the once place. If Ryan has no solution, then I might consider removing modules from the list that have know issues (like the ProcessWireUpgradeCheck one). Agreed - I'll start thinking about this.