adrian

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.

The latest version has several tweaks, and one potentially valuable new config setting. The debug mode panel has the option to NOT show the debug tools when debug mode is off. This might be nice on a production site where you have forced superuser into development mode - you still like having the reminder to confirm that debug mode is actually off, but you don't want all the tools displayed - it is potentially a big performance improvement on some servers.

Here's a few more - not sure whether you consider them simple or not http://modules.processwire.com/modules/version-control/ http://modules.processwire.com/modules/process-hanna-code/ http://modules.processwire.com/modules/process-jumplinks/

This panel has been added to the latest version! Just like the core module disable option, it is only available in PW's advanced mode and only for autoload modules. Please don't use this on a live site - it's not a problem with this panel, but rather the core module disable flag. It can break your site quite easily with some modules. For example, disabling the ProcessWireUpgradeCheck module results in a fatal error and the only way to fix is to manually remove the disable flag in the database. I am not sure whether Ryan might be able to fix (https://github.com/ryancramerdesign/ProcessWire/issues/1990) this in the core, or in the ProcessWireUpgradeCheck module itself, but it's definitely a good indicator that you need to be careful and savvy to be able to fix things if they go wrong! Still, hopefully you will find it useful - it is certainly a lot easier than going through all your modules in the admin and disabling them there. Let me know how it works out for you.

Lots of discussion, links and approaches in this thread:

Thanks - looks like I forgot to pass the length and depth settings to the dump method. I'll sort that out in the next version. The depth should actually make a huge difference to the size of the panel. I'll see what I can do about that - looks like I need to force it to wrap. Tell me about it - sometimes they try to simplify to the point of losing functionality!

Thanks @szabesz for your input on this - definitely some good ideas. A couple of quick comments/questions: Could you PM me the html from that panel - I'd like to see why it is so large. I can already see that I am not getting the array of ML titles - it is still returning an object, but based on the size, I am guessing there are some other objects also in the Value column. Rather than jumplinks to sections, would you be ok with collapsed sections, like the PW Info panel? I like the idea of highlighting variables only used once - it was something I had also been thinking about. Looking at your $authors variable - is that actually one of those things that should be highlighted - is it really just defined there and never actually used, or is it used twice on that line, or there a problem with my detection of it only being used on that one line? "It would be nice to have a "collapse/expand all toggle" for arrays/objects" - what arrays/objects don't have this already? I thought it should be all. Not sure about making strings collapsible - this is a core Tracy feature I am using to make arrays/objects collapsible. You can set the length of the string in the config settings though (default is 150) - does that help? Also not sure about turning columns on/off - does the width of the panel matter that much, or is it more the height that important? Also curious what others think of the recent additions to this panel - is it getting to be too complicated? I haven't tested with complex pages with lots of template defined vars, so maybe it does need some refining - seeing your 1.1MB is not a good sign, but I think that can be dealt with so long as I convert all objects to arrays of the relevant properties/values rather than the full object.

Curious what you guys think of making the Dumps Recorder panel enabled by default when installing Tracy? I don't think there are any real disadvantages and it overcomes an issue where users may wonder why the core dumps panel doesn't show their bd() calls (multiple ajax requests, php redirects etc). Any thoughts? Actually on this topic, are there any strong feelings in general about the default list of panels?

Ok, thanks to some testing and tweaks from @tpr, the Dumps Recorder now has a "Preserve Dumps" checkbox. When checked, dumps will be preserved until the session is closed. With it unchecked, they will be automatically cleared on page unload. This means it will store all consecutive ajax called dumps, and any dumps during php page redirects (which would be lost with the normal core Tracy dumps panel), but not burden the panel with lots of data unless you specify. The "Clear Dumps" button is there if you want to have a clear slate while testing ajax calls without needing to reload the page to clear. Let me know if you find any problems or have suggestions for improvements and don't forget to like @tpr's original post suggesting this option.

Hey @tpr - just looking at this in more detail now. I hadn't thought of triggering this client-side, but I think it might make sense - is your thought that it's probably the easiest way to prevent a clear from being called during a PHP redirect or AJAX call? This way it has to be due to a page change or reload? I think that makes sense, but a couple of problems I have noticed: It actually only works reliably for me using beforeunload - I think Chrome doesn't accept unload It uses jQuery, but I want to make Tracy vanilla js only because we can't be sure that jQuery is loaded on the frontend Nice work of figuring out the need to init the panel if it wasn't ever opened, but I think I have a much easier solution all around which is as simple as: window.onbeforeunload = function() { document.cookie = "tracyClearDumpItems=true;expires=0;path=/"; }; Setting that cookie is actually the key part of the clearDumps() function - with that set, the dumps are removed from the session variable. There is no need to call the entire clearDumps() function because we don't need to remove the dump content from the DOM of the panel instantly - we can rely on the PHP code to do it on the next page load. Does that make sense to you?

I should have also pointed you to this post which explains more about how to use implode, including using it with <li>

I don't see anything wrong with your videos foreach, but look at the Cast line from your OP, you can't simply output $page->cast assuming "cast" is a page field. There are multiple ways, but perhaps the easiest for the way you have your code structured would be: $page->cast->implode('<br />', 'title');

A multiselect will return an array, so most likely you will want to foreach through it - something like this: foreach($page->pagefieldname as $p) { echo $p->title . '<br />'; } There are lots of other ways to grab the data so tell us more about your needs and we can help further.

Thanks for the report @szabesz - can you please check if the latest version fixes both of those for you?

Interesting idea for sure. The thing is that I am not sure that I would always want it to auto-clear. There are times when I want to compare the results of one dump with another (perhaps after a code change), or even on a different page. It could be a configurable option though - on the module settings page, or maybe a checkbox on the panel so you can easily uncheck when needed. What do you think? I think the idea is great, just not sure how easy the implementation is. I can't find Ryan's notes about the module disable feature he added, but he only made it available when in advanced mode because he mentioned there can be some big side-effects in the case of some modules. I guess I could also limit to advanced mode and add the same caveat. Here is the text from the source code where the disable module checkbox is added (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessModule/ProcessModule.module#L1280): "Be careful, checking this box can break the module or your site. Use for temporary testing only."

Thanks for the confirmation @tpr. Minor update just committed adds the filename and line number of defined functions, and links to open to that spot in your code editor. Should be a nice addition when you don't remember where a function is defined.

Not directly answering your questions, but when it comes to getting page creation with complex fields happening on the frontend I actually really like this module: https://github.com/teppokoivula/AdminBar - this is an updated version of the one created by apeisa which works in more recent versions of PW. I like to use this as a starting point and add some custom styling and tweaking to suit the site look and its needs. You can limit it to just the pages you want (in your case the blog). I am honestly not sure why it's not more popular, but maybe it's just me who likes it PS - maybe it is overkill or maybe not appropriate for your project, so as @Robin S says, it's definitely possible to get CKEditor working on the front-end.

Hi @rolisx and welcome to the forums. foreach ($pages->get('/shows/')->children("show_date<=".time().", sort=show_date') as $show) { and then another one where the show_date is greater than the current time()

You might also find this option useful:

Not sure if this really belongs here, but interesting to see that: http://www.burgerking.it/ is running on PW and yet several other of their regional sites, eg: http://burgerking.ca/ are running Drupal. Sites looks very similar visually.