adrian

@celfred - I would need superuser access to the site to be able to test the issue of the pages loaded going to the 404 and also the issue of it appearing in the backend when not checked. Don't worry, you can trust me Obviously PM the login details.

@celfred - any chance this site is on a live server somewhere and you could give me access to figure out what is going on. PS Are you running the latest version of Tracy?

FYI - that last change regarding exception handling in the Console panel only seems to be working here on PHP 7 - on PHP 5 it reverts to the full stack trace result. Not sure if I overlooked something or what just yet, but if anyone feels like testing a simple syntax error in different environments and let me know what happens, that would be appreciated. Thanks!

Thanks for your ideas on this. I must admit though that I never have a need for the labels to be displayed (I actually think they look horribly ugly), so I am not convinced about the three-state toggle, but I am open to being convinced if enough people would like it. I probably agree with you regarding not needing the new setting to hide bar by default - I added it anyway, just in case it's easier with very small touch screens where it might be hard to hide in the first place - maybe not really that hard? On another note, I just committed another update which adds nicer/simpler exception reporting for the Console panel. I was getting tired of the Tracy "Bluescreen" showing the full stack trace for a simple syntax error in the console. I wonder if at times my changes might hide useful info though, so I'll keep an eye on things and maybe add an checkbox option to turn on the full trace if checked. Please let me know how you find this new approach.

@gmclelland - I decided to go ahead with adding this anyway The latest version replaces the existing close (x) button with a hide arrow. This is what it looks like when hidden: In case anyone is wondering, this is quite different to the Enable/Disable button (either from the dedicated panel, or from the panel selector) because with this new option, even when hidden it is still capturing errors etc and when you unhide/show it will instantly show it's information without the need for a page reload. There is also a new module config setting to "Hide Debug Bar By Default". That should be self-explanatory, but keep in mind that once you have clicked on the show or hide buttons, cookies take over controlling its status. Please let me know if you have any problems. Just an FYI - I am not a big fan of this because you won't be alerted about non-fatal warnings/notices while the debug bar is hidden, but I think it's nice to give users the option if they prefer it.

@gmclelland - have you tried unchecking "Show Panel Labels" ? I do that on all my sites. The only reason I have it on by default is for new users so it's easier to know what the panel icons are. If that's still not enough, I'll have a think about the hide toggle for you.

Have you thought about using WireCache instead ? https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

Just trying this here: d($page->repeatertest->find("language=".$user->language)->each("author_name")); In this case I am using the system "language" field, rather than a page field and I am reporting the author_name which is another field within the repeater. It actually seems ok here

Can you find the actual repeater item, or just the page that has a repeater item that matches the find?

@flod and @Gideon So - I just committed a new version which automatically adds the Repeaters parent to the list of branch exclusions. I would appreciate it if you could please check if this takes care of image uploads in repeaters without having to manually add it in the config settings. Thanks!

Yes of course - sorry, you can't actually "find" a specific repeater item. However one thing you might prefer is rather than using a Page field for the language, just use the built in "language" field.

Glad to hear. I am actually thinking that perhaps the Repeaters parent under the Admin should be automatically excluded. That config setting should really be for PageTable parents and other things that maybe in undefined locations, but we always know where the Repeater parent is.

@flod - exactly as @Gideon So suggests. You are looking for the "Branch Edit Exclusions" setting: "Selected branches will be excluded from branch edit restrictions. They still won't show in the page list, but they will remain editable, which is useful for external PageTable branches etc." I suppose it should also mention "Repeaters" as well as PageTable branches. Please let me know if everything works properly once you take care of that.

https://towait.com/blog/processwire-field-template-module/ http://page-online.de/tools-technik/processwire-ist-ein-schlankes-und-flexibles-cms/

Nice one! Try this: $page->langFiles->find('lang.name='.$user->language)

Just seems like it would be an easy way to check access. You could of course do a partial match, or match a custom field on the user template for each user against the page name. Lots of options - just depends what suits your needs the best and is easiest to maintain depending on how the users are added to the system.

Correct - that is how those language alternate fields work. Just add the name of the language as a suffix to the base field name and it should all be taken care of automatically. Maybe not the cleanest solution because you do need a new field for each language, but other than that it works seamlessly in my experience.

Haven't used it, but does this module help: http://modules.processwire.com/modules/ajax-intercooler-js/

Just hook into Page::render or Page::viewable and check the user name against the page name. Sorry, no time for example code, but take a look at the Page Protector module - it should help you with code.

Works great for file fields for me - I use it for different language versions of the same PDF report. I don't think you want outputformatting off though - you'd want it on to get the localized version of the file and its description. Maybe someone with more ML experience might have an idea why it's not working for you?

This is the approach I use for ML file fields: https://processwire.com/api/multi-language-support/multi-language-fields/#language-alternate-field-values

I don't know what your ajaxSave() method does, but get it to save the file to a temporary path, then do: $page->image_field->add("path_to_temp_image"); $page->save("image_field"); and everything should be fine.

Options needs to be an array: array('upscaling'=>false)

That makes sense for sure. When I sent you those other links, I assumed that the usernames would be different to the email address.

Something sounds wrong there - are you sure you don't have something else that is handling the email to username check? I don't see anything in the login method to handle an email: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/Session.php#L704 and it doesn't work for me.