adrian

Anyone new to this module, please be aware of this unfixed issue: https://github.com/ryancramerdesign/ServiceCurrencyConversion/issues/1

It doesn't diminish your request, but Interestingly I have an issue where AOS actually causes a horizontal scrollbar to appear on desktop on some pages - as soon as I disable AOS it goes away. I haven't narrowed down the cause, but something worth thinking about in all this.

Thanks @Macrura - that got me on the right track - should be fixed in the latest version.

Hey @Macrura - you gotta give me more than that 🙂 Seriously though, it looks like there is something breaking output for the Server Request section, or perhaps it's actually being broken in the preceding Field List & Values section. Could you please try disabling those two sections (in the config settings there are checkboxes) and see if that fixes things? Then perhaps you could narrow down what part of the section is failing please? My gut feeling is that it is the Field List & Values section and there is some field that is breaking things. Thanks.

Based on the available methods in this module, it seems like the best approach is actually now: $map = $modules->get('MarkupGoogleMap'); echo $map->getGMapScript(); You can see here: https://github.com/ryancramerdesign/FieldtypeMapMarker/blob/917edef8efe92bf8bdbdff62b66f6eca581ca57e/MarkupGoogleMap.module#L154-L165 that this will return the entore script tag you need, along with your API included. Of course it would be nice if the module docs mentioned this 🙂

Just added a small feature that fixes a big pain point for me. When editing a page, there is a new button in the AdminTools panel to change the "collapsed" status of all fields to fully open and editable. This is great for those fields that you don't want available regularly (especially for non-superusers), but occasionally need to view or edit. Fields will remain like this until you click this alternate button, or the site cookies are cleared. Hope you find it useful!

@teppo - yep, you have understood exactly what I am suggesting. I agree - I don't like long click / double click. Perhaps just a dropdown from the "Edit" link that says "Edit in Admin". But of course the main top-level Edit link would edit in the overlay, so no need to wait for the dropdown to appear when wanting to edit this way. ??

The term "Setup" doesn't make much sense to me either for things other than Templates and Fields and perhaps others like Languages etc. But the nice thing is that you can rename Setup to something else if you want, or move any of it's children out to the top level, or under another parent you might create, perhaps called "Tools" or whatever you want.

Awesome - thank you @teppo Not sure if this is a good idea or not, but what about a way to choose between edit modes from the AdminBar? Inline Edit vs Admin Edit, or something along those lines. Not sure whether they should be separate buttons, or a dropdown for the alternate (not default) method, or perhaps long-click (although this takes training users so not sure this is a good idea). I just feel like sometimes you know you will want to edit other pages after this one so it's a shortcut to the admin along with editing the page. Maybe it's getting too complex though, so no pressure 🙂

Hey @teppo - you raise some interesting points regarding Tracy's output mode. Honestly I think when I initially set that logic up I wasn't certain of the approach that would make the most sense so what we currently have may not be perfect, but here are my thoughts on the current state of things. In Production mode Tracy logs and emails (if set up) errors, but doesn't display the debug bar or errors on the screen. Unless you are a superuser or other authorized user, all sites will be in Production mode regardless of this setting. If you are a superuser and the output mode is set to Production or Detect (and the site is on a live server) and the "force" option is not checked, then Tracy will be in Production mode - I guess my thinking around this is that some superusers may not want Tracy to be in Development even for themselves when a site is live, but that on the dev version of their site with all the same settings, they would like it to be Development mode. The reason it's not all tied to PW's debug mode is that if debug mode is on and for some reason Tracy doesn't capture the errors (unlikely/impossible I suppose), guest users may see PW/PHP error messages (not good!), so I like to have Tracy's Development mode tools (debug bar / bluescreen error stacks, etc) available for superusers even when debug mode is off on a live site. I hope that explains a little of my thinking, but if you are struggling with the way things are set up and would like to see changes, I am definitely willing to consider your suggestions - I haven't revisited this logic in many years! Re: breakpoints - sounds like you figured that all out in the end, but regarding the bp() method that is used by the Performance panel - that comes from the wording used in that Panel (https://github.com/Zarganwar/PerformancePanel/blob/master/src/Panel.php) which is clearly not a good use of the term and is confusing. If you're interested, you may like to look through the other 3rd party panels available for the Tracy core: https://componette.com/search/tracy - in particular there are a couple of XDebug related panels that you might find helpful - they don't seem to be actively developed anymore, but perhaps you could investigate and we could implement one into TracyDebugger if helpful. In general, I'd definitely appreciate any thoughts you have on Tracy and its functionality. Cheers!

Just noticed something in the new php.ini that is shipped with php7.3 ; The value is also used for json_encode when encoding double values. ; If -1 is used, then dtoa mode 0 is used which automatically select the best ; precision. serialize_precision = -1 The php.ini with php7.0 had the precision set to 17. Not sure what real world impact this will have though.

To be clear, PageRenameOptions does a lot more than fix this issue, and those in @teppo's camp who don't want URLs to ever change might think they shouldn't use it, but it comes with this option: which I think makes the module useful for anyone/everyone and actually I think even with this checked, it would solve this copy/clone issue because the cloned page is unpublished and so as long as the title is changed before it is published, it will still rename the page when changing the title.

There are several places that 128 is forced: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Sanitizer.php#L415 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Pages.php#L85 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L49 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L314 https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js#L60 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Inputfield/InputfieldText.module#L258 When creating a new page, it's the JS file that kicks in first and truncates it as the title is typed. You could override the JS one pretty easily (look at my PageRenameOptions for hints on how to do this), and also deal with the sanitizer by setting the name in a hook and resaving, and you could hook into InputfildText::processInput to deal with the dirty length truncation. I think the hardest but might be dealing with nameMaxLength constants that get used in PagesNames.php in the pageNameFromFormat() method. Definitely much easier to see if Ryan might relax the limit, or make it configurable 🙂

Thanks for your thoughts - I don't see Ryan having a checkbox for this on all page edits - I think there are too many folks who don't think a page's name (URL) should ever change. I guess I am talking about this only in terms of the copy/clone operation because I think it will create a real mess of page names with the current behavior. But again, my module works around this and it's the first thing I install on all my sites so I am not too invested in seeing this change happen but thought if others weren't aware of the way it currently works and don't like it, they might want to submit a Github issue. Any takers?

What does everyone think of the cloned page keeping the name of the source page? I am using my PageRenameOptions module so this doesn't affect me, but I expect most site editors who use the copy button won't expect that they have to re-"name" a new page to match the title.