Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/11/2019 in all areas

  1. Hey folks! Just released AdminBar 2.2.0. Here's what's new: New module config settings for selecting items displayed in the Admin Bar. New items, disabled/hidden by default: "profile" (simple profile edit link) and "user" (basically the same concept as the profile edit dropdown menu in Admin). If "user" is displayed, there's a config setting for items displayed under it as well. New hookable method ___getData(). The returned array is converted to an object and stored as JSON (data-adminbar) on the Admin Bar element. This was mainly added for future JS features, but can be used by themes etc. as well. Hookable methods and their primary purposes are now also documented in the README.md file. Quite a bit of code was rewritten – again. I've been splitting some methods to smaller ones to improve maintainability, fixing small issues, improving accessibility to some degree (still needs a lot of work though), etc. Hopefully didn't cause too many new problems in the process... ? Here's a screenshot with new items enabled, though one probably wouldn't want to enable profile and user (and all the user dropdown items) at the same time – and yes, my user name on this site is "admin", so it looks a bit silly when there's an "admin" link before and below it as well ? --- Thanks! This will be the next item on my list ?
    2 points
  2. 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!
    2 points
  3. Maybe not the direct answer to your question, but You can easilly enable/disable Tracy in config dependant on your $config->debug setting.
    2 points
  4. Nice! Thanks for the quick update! After I updated to the new version, the permission 'trigger-db-backup' wasn't available. I created it manually and now it works. Maybe the permission wasn't created because I updated, rather than installing a new copy? Anyway great update, triggering the backup on login is a nice option!
    2 points
  5. @jploch @horst Tonight a had a look in the module and I made an update to version 1.1.6 I removed any general permission from module. The Backup is triggered now by any user (if a time interval is set). I added trigger option when a user logs in (thanks for the hint @horst). I changed the name for the required permission (trigger on login or logout) from 'db-backup' to 'trigger-db-backup'. Also to prevent permission conflicts with ProcessDatabaseBackupsusing this permission.
    2 points
  6. Thanks for the reply, @adrian. Your logic makes perfect sense to me! I didn't think this through: I'm not used to debugging anything on production, so it didn't even occur to me that this way one can actually use Tracy on a real production / live site. I'll have to agree that enabling debug mode on production is a bad idea – partly because something may indeed slip through to the front end, and partly because some modules etc. may in fact behave differently (such as output some sort of debug log on screen) when the debug mode is enabled ? I can definitely live with this, it's really not an issue. Mainly it was just a bit confusing while getting started with the module. Awesome – definitely will check those out! I've only been using Tracy "seriously" as of this morning, but I must say that I'm quite enjoying it already. It's a massive tool and so far I've only used a tiny fraction of its features, but I can see a lot of value in it ?
    1 point
  7. Thanks Ivan! ? So it would seem that I can at least solve this by setting that $config->tracyDisabled based on my own rules (or just use the same rules by stating that "$config->tracyDisabled = !$config->debug"), and then setting the output mode to DEVELOPMENT (or alternatively forcing development mode for superusers, since that's what I'm usually logged in while developing anyway). Still would seem more "streamlined" if Tracy utilised ProcessWire's built-in debug mode flag, but again there may be a good reason why a more nuanced setup is required. ... although, now that I'm reading the docs more carefully, I'm also wondering if I should just stick with DEVELOPMENT mode all the time. I'm not entirely sure (yet) what's the harm in that, considering that only superusers and users with the tracy-debugger permission should see anything out of ordinary anyway – right? Or is this setting going to do/affect something else? Basically it seems that this setting is useful in case, say, a client is going through the site as a superuser and you don't want them to see the Tracy bar ? -- Another thing I've been wondering – and this is completely unrelated to the questions above – is whether Tracy provides support for breakpoints, as in points of code where execution should stop and display current "state" in some manner? I'm aware of the bd() function, but couldn't find anything pointing to this direction specifically. There is the bp() function, but apparently it's a different concept entirely – more like a timer than a breakpoint, really. Coming from Xdebug I'm used to relying on breakpoints while debugging features that I want to walk through step-by-step, stop before they are fully executed, etc. If the answer is "no", that's fine – I can always just use Xdebug on the side ? Edit: should've kept digging further. Found this from the blog entry introducing Tracy Debugger: I guess that answers my question above, and the suggested solution is indeed a combination of Tracy + Xdebug ?
    1 point
  8. @horst Sorry for the very delayed answer. The module (FieldtypeSelectExtOption) is a fieldtype, not an inputfield. The fieldtype supports any Core Inputfieldtypes (Select, Radios, Checkboxes, SelectMultiple or ASMSelect) furthermore some 3d Party Inputfields like InputfieldChosenSelect. Read more about this in the README.md. I don't know if there exists an Inputfield module which extends InputfieldSelect or InputfieldSelectMultiple showing icons or thumbnails to select from. Let me know if you find a solution.
    1 point
  9. 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.
    1 point
  10. Just a quick update this week. I’ve got a good post in the works that I thought I’d have ready for today, but didn’t have quite enough time to finish it, so going to save it for next week. Though there's a module that's part of the post, and since it is ready, I've posted it below. We’ll look at ProcessWire 3.0.138 next week as well. I do have a couple of non-core updates to mention this week though. First is that I’ve released a new Textformatter module that converts any image references in your CKEditor/textarea fields to WEBP images on-the-fly as pages are rendered. If you are implementing WEBP on your site, you’ll find that the images placed in rich text fields are the most tricky ones to serve as WEBP, so this module takes care of that task for you. It's in the modules directory or at GitHub: https://github.com/ryancramerdesign/TextformatterWebpImages I’ve also released new development versions of the ListerPro and Export CSV modules, both of which are available to subscribers in the ListerPro support board. Some of the new features are actually built into the core, but currently only utilized by ListerPro. There’s quite a bit of new stuff, so there’s also an ~18 minute screencast that walks you through them, which can also be found in the ListerPro board.
    1 point
  11. I kind of like it as we set things up there. A few years ago I didn't like the global use of page for absolute everything and the menu label setup... but nowadays it feels weird to have a global settings page/area as in WordPress or things like posts and pages. Maybe you can add your SnipWire (page) into the navigation bar next to setup somehow. And as far as I know is your module quite huge and almost a standalone version of ProcessWire... it would make perfectly sense to add it to the top bar. Disclaimer: yes... I'm sometimes weird, confused and do things differently.
    1 point
  12. Honestly I don't think that there's any deeper meaning here. Setup is always available and generic enough to contain different types of things. That's just about it. We could probably figure out some other "generic parent", but personally I'm OK with "Setup" -- though I do see your point, and do think that it's a valid concern ?
    1 point
  13. What do you mean with "better standard"? You can move your custom process module within 2 seconds. That's not really too cumbersome, isn't it? In this example, dashboard + forms are top-level links in the admin, not under "setup". The "default standard" prevents breaking the top-level admin links to have too many items and therefore maybe breaking the navigation (visually, i.e. two or three rows instead of just one).
    1 point
  14. Yeah - I've too often had to build complicated RockFinder queries and came up with this quick&easy solution one day and couldn't believe I didn't think of it earlier ? Don't tell anybody, but I've just started developing RockFinder2 with a new syntax that will be even easier to use and more intuitive and powerful ?
    1 point
  15. A hint on the module config page would also be fine ? "Install Process Module" or "Process Module is (not) installed" PS: Sorry, didn't follow this 14 pages thread closely enough ?
    1 point
×
×
  • Create New...