d'Hinnisdaël

This is fantastic. ? I also need currency that doesn't creep me out.

@Macrura ? Looks great! I do have a FormBuilder module on the longer wishlist, but can't see myself implementing that too soon. If you ever feel like creating one, I'd be more than happy to merge it into the main module.

@Macrura Yeah ? I added another release, check out 0.4.4.

@Macrura I released a version that should fix the auto-loading of asset modules into the config array.

@Macrura Shortcut URLs I have pushed a release that treats strings as URLs so that any of the following options should work: [ 'shortcuts' => [ // Page $this->pages->get(1132), // Page ID 1020, // Overwrite page title 'New things' => 1020, // Set custom URL 'Backups' => "{$config->urls->admin}setup/db-backups/backup/", ], ] Profile page icon Check out the PageIcon module which lets you set custom icons for every page. Hooks in admin.php That's strange. Do you have any other hooks in admin.php that work? I have tons of hooks there and never had a problem. $config->styles True, I don't use the styles array myself so I haven't run into this. Will research a fix.

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

Completely agree. The module will only profit from you enjoying working on it, so go easy on yourself and make use of available core features where necessary. Besides, ProcessWire is ridiculously easy to keep updated, so I don't feel like you're leaving anybody behind.

I'd use the module uploaded by LostKobrakai at some point and add margins and paddings to position them at north/east/south/etc:

Yes, working as intended!

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.

@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.

@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.

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.

Very much in favor of adding hooks to add custom URLs!

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.

Is the default language tab still initially active after you increase its sort value? Or does PW always focus/activate the first visible tab?

@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?

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.

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.).

@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.

@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 ?

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.

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.

This looks great! I've set up my fair share of Snipcart sites, but never bothered to abstract any of it into a module. So thanks for making this available in whichever form you're comfortable with, free or paid. My Snipcart styles have usually been very tightly linked to the site stylesheets (shared SASS variables and mixins) and ended up in the global site stylesheet. Maybe the stylesheet URL input shouldn't be mandatory for sites that already have the Snipcart CSS embedded? Just a thought.

True. Many of the recent API updates are about privacy, which is a good thing. But the rollout was more than ideal. And I'd love to go the official way and use their API. But I get emails from clients every other week, asking about invalidated API tokens after they log in from a hotel wifi. And setting up API tokens is quite the hassle. So yeah, it's scrapers for now…