adrian

I have just added a new config option for hiding the debug bar in modals. @tpr and I discussed this above and we decided to show in regular modals, but hide in inline ones, but the tripling up of the bar when editing a page in a modal and then editing an image from that page was driving me nuts, so now the default is to have it disabled in both modal types, but you can uncheck these if you want.

Here's another one: Seems to happen after a field has been collapsed.

Great to hear. I have restored your listing on the sites page: http://processwire.com/about/sites/list/cms-critic/ @Jonathan Lahijani - if you want to send me the details you want entered in the Made By section, I'll update that too!

Glad it's working. Just a couple of FYIs for using Tracy with modules in case you missed them from above. If it's an autoload module, then sometimes Tracy isn't loaded before the module (nothing I can do about this until Ryan gets back to me). The other thing is that sometimes it pays to use the Dumps Recorder panel with "Preserve Dumps" checked as sometimes things can get lost during redirects within modules. This way, a simple reload will refresh the content of that panel and you'll have your dump.

bd() and all the other shortcuts are available in the global namespace so you shouldn't need to do anything special. Is that not working for you? Does it then actually work with use\Debugger" & "Debugger::barDump(...) ? If so, could you perhaps give me more info about where in the module you are trying to make the call?

What version of PW? You need 3.0.5+ for nested repeaters to work properly. https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ (read the "New support for nested repeaters" section). You might also want to consider the repeater matrix option which is only mentioned in that post.

The FileCompiler only compiles files if there has been a change to a file since it's last compilation. So once you deploy, if you don't change any template files. or update any modules, the file compiler doesn't do anything. If you then make a change, it will compile the one time (likely when you view your changes) and that is it, so the users will probably never have to wait for it to compile. That said, the only time I ever notice the file compiler is during an upgrade of a site from 2.x to 3.x when it has to compile all template and module files at once. I have never noticed the time for compiling one file. If you are seeing peaks from the file compiler on every page load, maybe there is something amiss?

Just posting a teaser at the moment because I am not yet sure if this should be a standalone module, or part of the still unreleased Module Toolkit (https://processwire.com/talk/topic/8410-module-toolkit/). Now available here: https://processwire.com/talk/topic/15702-module-settings-import-export/ It is quite simple in its execution - it adds a Settings Import / Export collapsed fieldset to the top of the module settings page of all modules. You can copy settings from one install and paste into another and click "Import Settings". It works quite like PW's core template and field import/export functionality. Simple as that PM me if anyone is keen to try it before I decide where and how it should be released. Settings are automatically saved when you uninstall a module, so you have an easy way to restore them when you uninstall. Anyone have any thoughts on any of this?

Definitely 3! Here is a slightly outdated review of changes between 2 and 3: https://processwire.com/blog/posts/review-of-processwire-3.x-so-far/#whats-changed-between-2.x-and-3.x

boo! hiss! Just kidding I actually don't mind it at all now that the crop again option is a button rather than a text link.

It looks to me like they should both work just fine. Just one thing to mention though. You could simplify the whole thing to: if($wire->users->count("email=$em") === 0) { $validMail = 1; } else { $validMail = 0; } or in my mind, even better: $validEmail = $wire->users->count("email=$em") === 0 ? true : false; Of course you could do the 1 : 0, but I think true : false is more appropriate because then later on you can do: if($validEmail) { Note in both cases I am also using 'users' instead of 'pages' which is more descriptive in this case. Also, using the PW count() method is much more efficient as it doesn't actually grab all the data, it just counts matches. You can even take it one step further if you only need to check if it's a valid email just one time: if($wire->users->count("email=$em") === 0) { //email is valid so do whatever here - maybe this is where you add them like: $u = new User() // etc etc }

Maybe at job for @tpr and AdminOnSteroids?

Here are a couple of example modules that do this already: http://modules.processwire.com/modules/process-email-to-page/ http://modules.processwire.com/modules/process-custom-upload-names/ The approach is the same in both, although I don't honestly think you should steal code directly as it's not particularly pretty (a big understatement) - I'd like to redo the approach for both at some point), but it will hopefully give you a starting point.

yeoman generator for processwire env: https://www.npmjs.com/package/generator-processwire

Just wanted to say a special thanks for this comment - I am very glad to hear it's been so useful to you - several of you have also been instrumental in making Tracy as useful as it is, so thanks to you all as well!

Firstly, thanks to everyone who has suggested a Donate button - I am still thinking about this - not sure what my thoughts are yet. Just a quick update on the ProcesswireUpgradeCheck module and the Modules Disabler panel. Ryan has fixed the problem in the latest PW core commits today, although he is still warning (https://github.com/ryancramerdesign/ProcessWire/issues/1990#issuecomment-243401979) about disabling modules. See my next comment about @tpr's approach of storing module settings when uninstalling - as I mention, I am not sure this is without problems as well. I'd like to see a bullet-proof solution, although I am not sure there is one. At least for now, this panel should be a little safer than it was, but I am definitely keen to improve the approach used if anyone has any great ideas!

I'd love to see this - I don't think it is taking away from PW branding - in fact I'd be happy to see the PW logo in the footer instead. I think as well as making the client feel like it's a system customized for them, I think the actual key benefit is providing another key visual trigger to let you know what site's admin you are currently looking at.

Not to be a feature stealer :), but I wonder if an icon/label on the Tracy debugbar might be a decent approach for this? Maybe not if you don't have the debugbar enabled in the backend? Or maybe if you typically don't want it on in the backend, then you could just have this "PW Instance" panel enabled for the backend, but no others? I was thinking of adding a field where you can type the "label" for the current site - ie "Dev", "Staging", "Live" etc and then would be displayed in the debug bar. You could also choose an icon color along with the label. Any thoughts on this vs coloring the header via AOS?

@horst is right for sure. The other possibility depending on your needs is this:

mod_security is the devil!

I just checked your code here in Hanna's Test code option and it worked fine. I got myself my own form action link, but otherwise used your code. I used the text/html option. Sorry not much help I guess

What do you expect, you're living in the stone age Seriously though it would help if you posted code rather than an image so we could help test, but on that note, do you really want your MailChimp "u" and "id" public in this post? Maybe they are not important - I am not a MailChimp user so not sure on this.

This is a great idea (better than mine) if nothing in the module needs to work on the frontend, but one thing to note - if you change the autoload from true to template=admin you will need to do a Modules > Refresh to have the change take effect - I remember pulling some hairs in my early days of module development wondering why it wasn't working

@operat - welcome to the forums! Here's some info on the field that LK mentioned: https://processwire.com/blog/posts/processwire-3.0.4-repeaters-revisited-preview-of-profields-matrix/#new-profields-repeater-matrix-field

Looks really great @renobird - I know you say it it is specific to your environment and not meant to be released, but are you rethinking that? The one thing that we discussed in the Tracy thread about this was the ability for the tickets to be initiated from a link on every page so the user doesn't need to specify the page, and also so that the devs can view tickets relevant to the page they are viewing. I'd hate to see us all reinventing the wheel here - how can we move forward?