Jump to content

d'Hinnisdaël

Members
  • Content Count

    51
  • Joined

  • Last visited

Community Reputation

72 Excellent

About d'Hinnisdaël

  • Rank
    Full Member

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

1,414 profile views
  1. Yes, working as intended!
  2. Just gave it a try — works like a charm! Thanks for merging so quickly. A thought on the hook name: would it make more sense to call it getAdditionalPageUrls (including "urls") to clarify it's returning additional URLs for a specific page? One might need a hook at some point to get additional pages independent of any other page (who knows why), which would then appropriately be called getAdditionalPages.
  3. @Mike Rockett @teppo I created a merge request on GitLab. Happy to get some input on that. It includes an example implementation and an updated readme section on dynamic URL segments. One thing that I couldn't figure out is creating alternate-language URLs inside the hook. The LanguagePageNames module doesn't create the hooks for Page->localHttpUrl() if the requested page results in a 404 error (which it always does when generating the Sitemap since that's what triggers it). That's why the Sitemap module manually adds those hooks when initializing. However, even when the module has been initialized and the hooks should have been added by that point, localHttpUrl() is not available on any Page object inside the hook. I worked around that in my previous project by doing the same as the Sitemap module and adding the localUrl methods manually. It's however far from an ideal solution to have to add all that boilerplate. Any ideas? wire()->addHookAfter('MarkupSitemap::getAdditionalPageUrls', function ($event) { /* get arguments */ static $hooksAdded = false; if (!$hooksAdded) { foreach (['localUrl', 'localHttpUrl', 'localName'] as $pageHook) { $pageHookFunction = 'hookPage' . ucfirst($pageHook); wire()->addHook("Page::{$pageHook}", null, function ($event) use ($pageHookFunction) { wire('modules')->LanguageSupportPageNames->{$pageHookFunction}($event); }); } } $hooksAdded = true; /* add URLs */ }); I started working on the video element feature, but that's not as straightforward as I thought.
  4. @Mike Rockett @teppo I just stumbled upon a local fork to the module I made some time ago that adds that functionality (additional URLs per page, added via a hook). I'll whip it into shape and create a merge request in case that provides useful or as a starting point. It's working quite well locally, just have to fork from the current state and add some docblocks.
  5. Another related feature that I've thought about often is a hook for adding custom resources. The main use case would probably be videos tied to specific pages. As there is no agreed-upon way of uploading videos in ProcessWire, the module can't know what is a video and what isn't. Hooks would be perfect here.
  6. Very much in favor of adding hooks to add custom URLs!
  7. I can highly recommend @kixe's PageIcon module. It adds page_icon as a global field with a FontIconPicker input field. Works great for one-off changes, e.g. specific listers or module pages in the setup dropdown. For dynamic icons (warnings, etc.), the hook is the best solution.
  8. Is the default language tab still initially active after you increase its sort value? Or does PW always focus/activate the first visible tab?
  9. @ryan Do the custom file fields currently support FieldtypeOptions? I created it in my ›field-image‹ template, but it isn't shown in the image editor UI (no markup created). Checkboxes, text fields, page selects all seem to work fine. Your screenshot in the introduction blog post looks like it's using FieldtypeOptions fieldtype with radio buttons. Or is that a Page field?
  10. Looks like they went back to their previous pricing model without a premium plan. This will make it a lot easier to suggest Snipcart in the future — paying 70$ a month for custom email templates was really limiting the number of customers that were a good fit for it.
  11. You're right in that it's nearly impossible to tell which page to edit just from the URL. I think the only reliable way of getting the correct edit link is to render the admin bar server-side using wire('page'). No need to make it overly complex, I guess, by going the JS route. If somebody decides to do partial content replacement in their frontend, I feel like that's just something they have to take care of themselves by including the admin bar in the list of replaceable containers. The more I think about it, the more I feel like my case applies to that rule as well. If I want the links to force a full reload instead of a replacement, I need to configure my frontend accordingly. My only remaining gripe is probably the logout button that shouldn't be an anchor 🤡 As far as I know, it wouldn't make a difference since most libraries don't care too much about accessibility and tend to define their own cancellation methods (data-no-turbolinks="true", etc.).
  12. @teppo Those are some good points. I agree the admin link itself and the edit link should stay anchor tags. Create, browse and logout, however, aren't semantically speaking links since they potentially have side effects (create, logout) or only trigger module JS (browse). There is one case that will create pages by merely following a link: when a template is configured to use the »Name format for children« setting in order to skip the page-add step. In that case, a new empty page is created every time the link is opened. I use that setting on most templates, that's probably why I noticed. The logout could be implemented using just a form and a submit button, using the form action for the logout URL. Not sure if ProcessWire currently supports custom redirect URIs after logout or if you might have to hook into the logout process for that. Turbolinks in particular switches out the whole body, but the problem here is that since there's no actual reload, stylesheets and scripts stay active on the page, so you mostly need to make sure that you don't cross between frontend and backend with any of these libraries, whatever part of the HTML they switch out. I've found a hacky solution by canceling any AJAX page visits if the URL matches the ProcessWire admin URL, but that means the frontend code needs to have a 3rd-party backend module in mind, which feels wrong.
  13. @teppo I just installed the module but noticed all links are anchor tags, which is a bit problematic since these links can be triggered involuntarily by scripts or browsers prefetches. When combined with frontend link preloaders (e.g. InstantClick) or browser prefetching (e.g. Google Chrome Page Prefetch), this results in newly-created orphan pages or mystery logouts. Is there a way the module can be updated to use buttons instead? This would also make it work better with libraries like Turbolinks or Barba.js which intercept link clicks to load them via AJAX and switch out the response body. I'd gladly create my own theme to do that, but figure this is also a security issue, so it might be best to tackle this at the root level 🌝
  14. Doesn't LazyCron hook into ProcessPageView::finished to avoid this exact problem? What I've done in the past to avoid long-running requests is to merely use LazyCron to trigger the time-intensive action via curl or wget, making it asynchronous.
  15. Very nice — I'm really impressed about how this is coming along. I particularly like how you manage to pack as many features into it while successfully staying within ProcessWire's visual language. I wish I had a little more time on my hands to try it out in depth and give useful feedback. That sounds like a logical next step to me: using LazyCron to auto-fetch certain data. While it will increase complexity in the short term, it will probably make your job a lot easier in the long run and make for a better experience using the module.
×
×
  • Create New...