adrian

New version fixes this notice. Sorry once again for the label issues

@Juergen - so sorry about the label translations - totally my fault - I was so used to pushing to the dev branch lately that I didn't think about breaking changes. I don't think it's worth reverting the change that broke those labels given how new this version is, but I'll be sure not to break that again.The undefined offset on line 322 is a different thing - that happens if you don't define the example numbers in a format - note the: | 61,07,45673456,123 at the end of the line. australiaNoCountryAreaCodeLeadingZero | {([phoneAreaCode,0,2])} {[phoneNumber,0,4]} {[phoneNumber,4,4]} {x[phoneExtension]} | 61,07,45673456,123 What I will do though is add default example numbers so you don't get that PHP Notice.

Just added a new option: "Hide Input Labels" that results in a more compact input. Not sure I would recommend this if you are also displaying the country and extension inputs, but if it's just area code and number, then I think it works well and would make sense to the user.

Thanks @Juergen - sorry about the description/notes issue - it's fixed in the latest version.

OK, v2 has been merged to master. Be warned about the breaking changes!

OK, v2 has been merged to master. Be warned about the breaking changes!

Sorry @bernhard - I replaced the first image after my initial post, and accidentally replaced the second one as well. Take a look now

JSON API response testing in the Console panel I know we all know about json_decode($var, true), but here's a useful tip when working with APIs that return JSON. Note that I am using the new shortcut for specifying a depth of 7 so I get to the deeper levels of the JSON response. Obviously that's a LOT nicer than:

Anyone following this thread have any issues with the dev version before I merge to master? I'll merge later today if I don't hear anything. Thanks!

Anyone following this thread have any issues with the dev version before I merge to master? I'll merge later today if I don't hear anything. Thanks!

You need to add: xhttp.setRequestHeader("X-Requested-With", "XMLHttpRequest"); This is something that jquery does automatically, but you have to do yourself with vanilla JS. I think you may also need to add this inside your xhttp.onreadystatechange function. xhttp.getAllResponseHeaders();

File fields are an array (unless you set maxFiles to 1), so you need to either foreach or first(), last() or eq(n) to get a specific file. $item->allegato->first()->url; There is no "items" property, hence the NULL.

I wonder whether a decent interim solution would be to build this into CustomUploadNames so we don't need a separate fieldtype - that way if the core ever gets support for this, it would simply be a matter of disabling the rule in CustomUploadNames, rather than reverting to the core file fieldtype. I could add a new option that retains the original filename. Perhaps I could make use of your sanitizer? Any interest in this approach, or would it just be overcomplicating things?

I don't ever trust site/templates. I figure that site/assets/files makes it pretty definite, but as @kongondo mentioned, I always test via: isit.pw The other thing that isit.pw checks (I think), is the "it" url parameter that PW uses for all page requests. I got there from: https://w3techs.com/technologies/details/cm-processwire/all/all

It's been out for about 10 days now, but I never really announced the changes here - wanted to see if there were any issues before publicizing. The new 4.9.x version is now available. Here's a list of the main changes: 1) New File Editor Panel Supports editing all files in your PW install (you can define the root as /, /site, or /site/templates Can be used as the handler for opening editor links from the debug bar (errors, log files, Captain Hook, ToDo, Template editor, etc), rather than your code editor. Can be enabled as the link handler for live sites only, or local as well if you prefer. Has "Test" functionality for all files so if you make a change, it will only appear for you and not other users. Makes a backup of the old version each time you save a change and provides a "Restore Backup" button to instantly revert. Supports in-code search & replace with CMD+F Syntax highlighting/linting for PHP, CSS, and JS This replaces the Template Editor panel, so that one has been removed. Handles fatal errors gracefully - this is the biggest feature in my opinion. The problem with most online file editors is that if you accidentally make a code change that results in a fatal error, it can be impossible to fix and resave because the system is not functional. This editor gets around this problem by using Tracy's custom error handling which allows debug bar panels to continue to work, so you can manually fix the problem, or click the "Restore Backup" button. Of course if you used the "Test" option, you don't even need to worry, because you are the only one to see the version with the error anyway. As a follow up to that last point. I have used the excellent ProcessFileEdit module for helping to debug some issues on other people's sites without needing FTP access, but a couple of times I have made a fatal error mistake and had to get them to restore the file, so this really is a huge feature for me! 2) Support for Process File Edit If you prefer ProcessFileEdit to this new File Editor Panel, so you can use it for handling debug bar links. Note that this won't give you the "Test" and "Restore" options, or the fatal error protection, so it's not really recommended. I added support for it before building the File Editor panel so decided to leave in case others prefer it. 3) Revamped Console Panel The code and results sections are now a "split" screen so you can adjust the size of one relative to the other with the bar in the middle. Handy for working, but especially handy when you want to post a screenshot to the forums "Large and "Small" versions of the panel - click the arrows at the top right of the panel - the large version can be very handy when you have lots of code or results to display Supports in-code search & replace with CMD+F 4) New maxDepth and maxLength shortcuts and new barDumpBig() method You can now replace dump or barDump calls like: bd($var, array('maxDepth' => 7, 'maxLength' => 500)); with: bd($var, [7,500]); You can also make use of the new: bdb($var); as a shortcut to: bd($var, [6,999]); 5) New SQL Query column in the Selector Queries section of the Debug Mode panel This is a great learning tool to see the selector queries that are run for a given page request, and what SQL query these selectors are translated into: 6) Removed old Legacy version of Tracy core It was getting too painful to maintain support for this old version. This means that TD now requires PHP 5.4.4+ 7) Namespacing and refactoring lots of Javascript code No feature changes, but code is now easier to follow and is much less prone to any name conflicts with your site 8) Reduced loading of unnecessary code Lots of refactoring here too - should see some performance gains 9) New default server type indicator in the debug bar Not a big deal, but if you want a server type indicator and don't want the full height/width bar, you can now have one in the debug bar - I think it's a handy visual clue when looking at /working on live vs dev/test versions of a site at the same time. 10) Lots and lots of bugs fixes, layout, and styling improvements It's amazing what you find when you're buried in the code for a couple of weeks solid 11) The new docs site that I mentioned earlier is now fairly complete - I just need to work on the Tips & Tricks section https://adrianbj.github.io/TracyDebugger Feel free to make a PR for improvements to the docs - everything is under the /docs folder in the main Github repo. There are also "Edit on github" links on each page so you can use those as well.

Remember I started to implement CSV export for repeater fields in the Batch Child Editor module. You mentioned it didn't work for you (https://processwire.com/talk/topic/6102-batch-child-editor/?do=findComment&comment=155702) but we could probably try to figure out why it didn't work at your end.

Not sure how well known, but they have some well known clients: https://www.integrify.com/customers/

I haven't tried, but does: optionsfieldname.title or optionsfieldname.label work?

Great for sponsor logos too so that no-one feels gipped.

@godmok and everyone! Ok, hopefully this is the last update before pushing dev to master. This new version moves the "example numbers" into the Output Format Options syntax so that you can specify different numbers for each format which is important so you can tell from the dropdown whether the numbers are being formatted correctly or not. The syntax is: name | format | example numbers For example: northAmericaStandard | {+[phoneCountry]} {([phoneAreaCode])} {[phoneNumber,0,3]}-{[phoneNumber,3,4]} {x[phoneExtension]} | 1,221,5673456,123 australiaWithCountryAreaCodeNoLeadingZero | {+[phoneCountry]} {([phoneAreaCode,1,1])} {[phoneNumber,0,4]} {[phoneNumber,4,4]} {x[phoneExtension]} | 61,07,45673456,123 Note that the example numbers are comma separated for each component of the number. You can see the output in the dropdown in this screenshot. See how I have a leading zero/two digit area code and 8 digit number for the Australian examples vs 3 digit area code and 7 digit number for North America. Remember that this new 2.x version needs a different syntax for the format options, so if you are upgrading from 1.x, you will need to adjust, or empty the settings to have the new defaults populate automatically. This is OT, but I think it's a good excuse to advertise @netcarver's awesome ModuleReleaseNotes which shows what's changed when you go to upgrade a module (using Ryan's PW Upgrade module). Most importantly it highlights when a module is tagged as having breaking changes, which this new v2 of FieldtypePhone has. I hate implement breaking changes, but sometimes you just have to I'll give it another couple of days for the dust to settle (and here back from you guys) before pushing to Master.

Glad to hear. While I am introducing breaking changes, I thought it was time to tweak the output format syntax a little. I have committed a new version to the dev branch. It is now recommended to put your spaces and dashes outside the curly braces, eg: {+[phoneCountry]} {([phoneAreaCode,1,1])} {[phoneNumber,0,4]}-{[phoneNumber,4,4]} {x[phoneExtension]} Compare this to the old version: {+[phoneCountry] }{([phoneAreaCode,1,1]) }{[phoneNumber,0,4]-}{[phoneNumber,4,4]}{ x[phoneExtension]} I think the new way is cleaner, because the space, dash, etc between number components are not actually part of the component itself. Note that for the country "+" or extension "x" you still want those inside the { } component delimiters because they actually belong to that component of the number. Does that make sense and seem like a logical improvement to you?

Sorry, I know I am getting way OT with this Tracy stuff, but just wanted to let you know that the latest version adds the SQL Query column to the Selector Queries section of the Debug Mode panel. It seems to be stable enough to release, but let me know if you get any errors. Hopefully this should be a useful learning tool.

You can manually build the export however she needs. I would recommend https://github.com/PHPOffice/PhpSpreadsheet so you can write directly to Excel format. I would write an AdminActions action so you can give her a form to choose what she wants exported.

Remember that these modules were built by different developers - CroppbaleImage3 is not an upgrade to the Thumbnails module. The Thumbnails module was abandoned and @horst was kind enough to build this one and also put together a script to make the migration as easy as possible. The conversion from Thumbnails to CroppableImage is the only issue I have had with migrating any of my sites from PW 2 to 3 - I think that is pretty incredible for a major version upgrade. I am not meaning to sound dismissive, I understand it's not a simple migration, but I don't think it should be expected to be automatic in this scenario - I hope you understand.

I actually think it would be a great addition to have a "test" option in the Console panel - something that reported the changes that will happen - trouble is I think it would be a huge amount of work to implement.