Jump to content

teppo

PW-Moderators
  • Content Count

    2,420
  • Joined

  • Last visited

  • Days Won

    64

teppo last won the day on August 11

teppo had the most liked content!

Community Reputation

4,489 Excellent

About teppo

  • Rank
    Captain Earth
  • Birthday 08/21/1984

Contact Methods

  • Website URL
    https://weekly.pw

Profile Information

  • Gender
    Male
  • Location
    Finland

Recent Profile Visitors

46,525 profile views
  1. Hey @tthom_pw! Looks like this isn't currently possible. I'm working on version 2.0 of the module, which will include quite a few changes in fact, and I'd be happy to implement this once that's ready to be released. Sadly I can't give you an exact timeframe – probably "sometime within next few months", but that's just about it. In the meantime you might find other modules more suitable for this purpose. For an example my ProcessChangelog creates a relatively easy-to-follow log of events – it doesn't integrate with VersionControl, so there's no way to link changelog with revision numbers etc. but if might be a more sensible way to get an idea of what changed and when. Hope this helps a bit.
  2. You're correct that AdminBar only applies to users who are logged in. There's no "guest user" when it comes to AdminBar – only superusers and users with the "adminbar" permission will see anything out of the ordinary. Regardless, since AdminBar outputs features visible on the front-end, it's very much connected with everything else happening there. What you're missing here is that being logged in won't disable those browser extensions or nullify the effects of third party libraries – so it's not true that those features would only apply to users who aren't logged in. As such, it's very important that admin bar is as "tolerant" as possible, so that it won't break or cause new problems if you decide to implement a new JavaScript library on your site (or enable a browser feature/plugin).
  3. You're right that browse isn't really a link – that's definitely one that shouldn't be represented by <a> tag 👍 Logout is a border case: technically it can be a link, just like it is right now, but you're right that it probably shouldn't be. On the other hand even changing it to a form isn't, in my opinion, quite enough – it should also provide and validate some sort of nonce/token, just to be sure that it can't be abused. There's no redirect after logout at the moment either, so that's not a major problem. Anyway, I'll figure something out for the next minor release of the module. Create is one of the cases where a link usually makes sense: it should be a link to the "new page" view in Admin in case the modal mode is disabled or JavaScript is for whatever reason out of equation. That being said, I've almost never used the "name format" option, so I didn't even think of that – that behaviour is indeed problematic and needs to be addressed somehow 🙂 It just occurred to me that my earlier explanation was flawed 😞 If you reload, say, just the <main> element within your <body>, and Admin Bar remains as-is, the links/buttons there will point to the wrong page. As such using such plugins you probably would need to reload Admin Bar as well. I could add support for modifying target/parent IDs with JavaScript, but that would still require extra steps for the developer anyway. Also thought about using URL in this case, but that wouldn't help, as Admin Bar can't know for sure if you're using "real" URLs or some custom format (via URL segments, History API, or something else.) Currently I'm thinking that an option for reloading / re-rendering Admin Bar via JavaScript might actually be the best option here: in most situations the module would work right out-of-the-box, but if you do use some sort of front-end routing / transition code, you could somehow tell it to update. Not a perfect solution, so any suggestions are welcome. -- By the way, if – and only if – it turns out that one/some links can't be easily switched to buttons without sacrificing something else, do you know if role="button" would help at all? I wouldn't use that unless I really have to (reinventing <button> with ARIA attributes is almost always just plain dumb), but this might be one of those cases where it's actually the most sensible approach – it would be an improvement in terms of accessibility, but I've no idea if it would help with preload/prefetch/etc. features 🙂
  4. Hey folks – a quick update: Wireframe 0.5.0 was released couple of days ago. Compared to 0.4.x this version mainly fixes bugs and improves performance – nothing particularly major, but if you're using Wireframe, it's a recommended update. On a loosely related note, Tracy Debugger has been really helpful in figuring things out, identifying bottlenecks, etc. Brilliant module 🙂
  5. Hey @chrizz. I'm moving this thread to the "Module/Plugin Development" area of the forum. Please post all module development related questions there – the main "Modules" area is only intended for support threads of existing modules. Thanks!
  6. Hey @kaz. Just a heads-up: I'm moving this thread to the "Getting Started" area of the forum. The "Modules" section is only intended for support threads of existing modules.
  7. Hey @opalepatrick – just a heads-up that I'm moving this thread to the Module/Plugin Development area. The main "Modules" area is only intended for support threads of existing modules.
  8. Thanks for the feedback! Replacing <a> tags with buttons was originally on my list, but I've been pushing it back as there are some additional considerations here: There are some "proper links" (such as the admin link) that should remain that way. As such, this wouldn't apply to all links automatically. When the modal ("slide overlay" in module settings) mode is disabled, almost every item should be a regular link – except for browse, which technically shouldn't do anything there, as in that case it's just an indicator of your "current state". Admin Bar should work regardless of JavaScript. This makes it more robust, and as such more accessible. That last point isn't an argument against using buttons, just something to keep in mind when making changes: everything should remain functional regardless, which could mean links by default (when JS isn't available, or working as expected) and buttons otherwise. Since default styling is now based on BEM, it should make this easier in some respects, though; technically what element is used shouldn't matter anyway. I don't actually see (m)any notable issues in the current behaviour. None of the built-in Admin Bar features will create any content without user actually submitting a form – and I'd be very surprised if a plugin did that on itself. The logout link is problematic though, you're absolutely right on that one – I've added this on my todo list, but not entirely sure yet how to handle it. I'm not familiar with Turbolinks, but the way Barba.js usually works is that you define a container, which you then switch with new content. I'm not particularly experienced in this regard, but to my best understanding you wouldn't usually define your entire <body> element as a container, and since AdminBar attempts to place itself as the last element right before </body> closing tag, normally this shouldn't be an issue – though again, this is just based on my (quite likely lacking) understanding of such libraries 🙂
  9. Thanks – this should now be fixed in the latest version (2.2.2).
  10. This is how Pageimage handles errors that occur while trying to create variations. You can view the relevant parts of the code here. I'm not entirely sure if the error is visible while logged in as superuser, but one option would be enabling debug mode via $config->debug in /site/config.php – this way it should be saved into the image-sizer log file in /site/assets/logs/. Note that you don't want to enable debug mode if this is a live site, though. Optionally if you know when the error is going to occur, you can manually output the $img->error property after the size() call 🙂 There are a few reasons why this can happen, so the first thing would definitely be checking that error message.
  11. Hey stanoliver! First of all, it's difficult to say exactly how to set this up without knowing how your site has been set up etc. but if you're looking for a simple solution, you might want to take a look at the search template in the "classic" site profile: https://github.com/processwire/processwire/blob/master/site-classic/templates/search.php. This is a very bare-bones approach, though, and as such it doesn't handle things like those highlights – but it might be a sensible starting point for your own custom feature. Just modify the fields to search from etc. I know you said that you'd like to achieve this without a module, but I do still think that SearchEngine would make sense here. It does quite a bit for you out of the box. Hope this helps a bit.
  12. Could you clarify this a bit, what kind of mistake are you seeing? So far I haven't noticed anything wrong here, so it might be browser-dependent, or perhaps even site-dependent (Admin Bar is affected by site styles as well, so there's always a chance for that). Please let me know what browser you're using, how it behaves – and if possible, a screenshot would be really helpful too 👍 You mean when you add items via config settings? The order there doesn't actually affect the order of items in the Admin Bar – at least yet. That's something I have on my todo list, but not sure yet when I'll get to it 🙂
  13. Hey folks! Just wondering what everyone is using these days for taking notes on Mac 🙂 I'm setting up a new laptop, and this need came up – once again. On my previous (work) laptop I used TextWrangler and stored notes as markdown files to a directory called "notes" as "YYYY-MM-DD_note-name-here.md", and on the one before that I used Evernote (not sure why but somehow that didn't feel particularly comfy). I've also tried OneNote, but overall it felt quite confusing, and perhaps a bit too "power user oriented". As long as I can take notes easily, store them in some sensible way (preferably ordered by date and perhaps tagged or something), and perform searches on them I'd be perfectly happy. For a while I thought I'd found the perfect solution in an app called "Bear", but turns out it's commercial, and I'd really prefer something free... though it's still on my list, in case I don't find anything better 🙂 Any suggestions – what do you use, and why?
  14. Thanks – this is now included with the latest release, 2.2.1 🙂 I made a couple of minor adjustments: in mobile size the dropdown was positioned slightly too far down so there was a gap between the icon in the bar and the dropdown, and the "ul li > a, ul li > strong" CSS rule was changed to ".adminbar__link" in order to avoid unintentionally affecting unrelated lists on the site. I'll have to think about this a bit, not sure yet how it would fit the module. Technically this could be a relatively simple modification: the dropdown feature used for the "user" item applies to any item that has a "children" array, so one option would be adding that for the edit link. Haven't tested this yet, so not entirely sure, but that's one option at least 🙂
  15. Just checking that I got this right: do you mean that while the "slide overlay" is enabled and Admin Bar links (such as edit, new, and profile) will normally open the edit view in a "modal" window, there would be some way to open the target URL without the modal instead – going to the "full" admin interface? 🙂 If so, I can see value in this idea, but I'm not yet sure how to make that happen without messing up the simplicity of the UI or causing potentially confusing side-effects. Take long-click for an example: in my experience it's actually quite common for users to long-click or double-click things by accident (or by habit), so in my opinion (in a web based GUI) it's usually bad UX for these to lead to a different outcome vs. "regular click". Anyway, I'd be interested in implementing this if there's a way to do it in a sensible way. And please let me know if I've misunderstood your idea 🙂
×
×
  • Create New...