teppo

Depends: you could provide such option, but don't really have to. FormBuilder, for an example, simply makes use of the wireMail() function, so you're automatically using an installed ("third party") WireMail module instead of the default one (if one can be found – and if multiple are installed then the first one found). When the WireMail module type was introduced all examples used this function, either directly sending messages using it, or instantiating a new WireMail object by calling it without arguments ("$mail = wireMail()"). Basically you should only ever use "new [WireMail class name]()" if you want to select a specific WireMail module instead of letting ProcessWire make that choice for you.

This is related to https://github.com/processwire/processwire-issues/issues/733. Simply put new WireMail() specifically instantiates a WireMail object, not WireMailMailGun object, so this is (kind of) expected behaviour ?

If I'm being completely honest, I've never really had this need, and I don't think that I'd have much use for this feature. Then again It's clear that you've built much bigger – and much more complex – admin side features than I've ever even thought of, so it's no surprise that your needs are also somewhat different from mine. For me the admin is mostly for managing content, and when that content needs to be viewed by non-content-editors, I generally prefer to create my own views for it ? While I do understand your reasoning here, at the same time I think that what should be in the core are features that are commonly needed. Like Ryan, I'm not really sure that this as a very common need, and as such I think that it might be better to solve it with a module (at least for the time being). Personally I'd be slightly worried about the security of this feature if it was in the core: sure, Ryan has been great at covering all the bases when it comes to security, but making notable tweaks to the permission system is still a potential risk. I get that it's even more of a risk when you add it yourself, but when it's a third party module there's zero chance of it affecting anyone who doesn't specifically install it. I was actually going to suggest this – but then I re-read your post, and realised that you had already ruled it out ? In my opinion this doesn't don't seem like a very hacky thing. Hooking before page and fields can be saved and preventing seems like a proper solution to me. If you do that and also hide the "save" buttons (and prevent submitting ProcessPageEdit form in other ways), you'll be really close to what you're suggesting here.

Just gave this module a try and it worked beautifully. Will definitely be using it in the future! One slight hiccup, though: after cloning the module from GitHub I couldn't find it anywhere in the modules list. Took me a while to realise that it was listed as "Text Autocomplete" instead of "Text Input Awesomplete". Might be something to consider in future releases ?

You've definitely got a point there, @Mikie. Getting the word out about Padloper is a goal worth striving for. While I don't think that Ryan should (or would, for that matter) include Pro-prefixed modules from other authors to the official shop, at least for the time being (it would cause a lot of confusion about the person responsible for said module), but getting the module included there isn't a bad idea overall. I think it would benefit ProcessWire as well to have an ecommerce module available via the official store, at least as an alternative way of purchasing. Perhaps that's something to consider in the future? ? Although renaming the module doesn't really seem necessary, words such as "eCommerce" and "shop" etc. definitely need to be mentioned in the context of Padloper. In fact they already are: current website states clearly what Padloper is, though from SEO point of view there are some additional steps that should be taken, and the site – particularly the home page – would benefit from some reorganising as well. Then again, I'm assuming that @kongondo might have a new site planned anyway ?

"Office 365 uses Azure Active Directory (Azure AD) to manage user identities behind the scenes. Your Office 365 subscription includes a free subscription to Azure AD so that you can integrate Office 365 with Azure AD if you want to sync passwords or set up single sign-on with your on-premises environment. You can also buy advanced features to better manage your accounts." https://docs.microsoft.com/en-us/office365/enterprise/azure-integration I've never actually set up things from the scratch on the Azure / O365 side myself, but it definitely sounds like it should be enough. The usual process involves setting up an app on the Azure side, so I'd look into that first – preferably you should ask someone (sysadmin, IT support, etc.) from the client to set this up, or at least help with it ?

I've used this on a couple of projects to authenticate against Azure, and can definitely recommend it. Getting the config right can be a bit tedious, but other than that it's a no-brainer, and the module does all the heavy lifting for you ?

For the sake of marketing and brand recognition I'd recommend not going with a generic name such as pw + [some commerce related term]. Best known brand names tend to be unique, and they don't really have to have any connection with the company/product (although they can). Trader is a decent idea, but I still think that Padloper is better -- not to mention that it already has some brand value, and an awesome logo ? just my five cents.

It can definitely get a bit confusing when multiple topics are discussed in single issue or thread ? Anyway, template cache is a separate feature, and the files it creates are not stored under /site/assets/files/. In other words: pagefileExtendedPaths is a feature related to Pagefiles, and has no direct correlation with template cache files. The point here is that while template cache files can indeed suffer from the same limitation that resulted in the creation of the pagefileExtendedPaths feature, whether pagefileExtendedPaths is enabled or not has no effect on that. If you're worried about scalability on the filesystem level, you may indeed want to steer away from the template cache feature – but this problem only comes into play when you have tens of thousands of pages with template caching enabled (32k+ for ext3 filesystem, 64k+ for ext4, etc.)

@Lutz, note that pagefileExtendedPaths is all about /site/assets/files/, i.e. Pagefiles uploaded through the Admin or added via the API. What Soma and Ryan discuss in that issue is implementing a similar, but likely separate, feature for the files created by the built-in template cache feature (/site/assets/cache/Page/). In other words that discussion is not about an issue with pagefileExtendedPaths, but rather a suggestion to add another similar feature for a different purpose ?

I haven't used this feature myself, but for what it's worth this feature has been in the core for a very long time, and I haven't heard of any issues regarding it in years. As such, I'm pretty sure that the "beta" label is something you can safely ignore by now.

Hey @gregg! If possible, please try updating the module to the latest version (0.12.0). This should resolve your issue. For the record, Fields::delete() expects an object implementing the Saveable interface as its first argument – so the correct syntax would be something along the lines of $fields->delete($fields->get('thefield')). Since you cannot use this method to delete a field that has been added to one or more fieldgroups (via templates), that might still fail though ?

Not that it really matters, but until now I was unaware that WebP even supported "lossy" compression for PNG images. Turns out that for PNGs one can indeed use either WebP-lossless or WebP-lossy, while for JPGs you're obviously always using WebP-lossy ? Thanks to @horst for explaining the use cases! I did also wonder why we wouldn't want WebP source images. Technically I still think that it could make sense (ProcessWire can be used for a number of use cases, but "displaying images online" is still the most popular one by a wide margin), but it isn't really such a big deal. Not to mention that I'm not sure how well supported WebP manipulation operations are (in GD/Imagemagick).

Hey Ryan! Just a quick note that you may have a cache invalidation issue going on: visited the blog root a while ago, and the latest post was still the one from last week. Checked the latest entry (from last week), and kind of accidentally spotted that the "newest blog post" link actually pointed to another post. Publishing a blog post probably should invalidate the cache for the blog page? I've noticed similar issue with the sites directory (directory root is often updated much later), and in the past I've also had similar issues with the modules directory (though not sure if that's still an issue). Of course not a major problem, but it's a bit problematic in the case of things like new blog posts, where folks might want to get their hands on them as soon as possible ?

@MilenKo, just a quick note that I've merged your thread into the existing Hanna Code module support thread. When you have questions regarding an existing module, please post them to the dedicated support thread (if one is available – you can find a link to the support thread from the Modules Directory entry for the module in question). Modules/Plugins area of the forum is intended for module-specific support threads, and there should be only one thread for each module. Thanks! ?

Moderator note: this is not a module support thread, so I'm moving it to the General Support area of the forum instead. Please keep in mind that the Modules/Plugins area is only intended for module-specific support threads. Thanks!

I'm wondering if the "override core module / multiple copies of the same module" feature would break after this, i.e. will ProcessWire understand that a .module file in /site/modules/ is a replacement for a .module.php file in /wire/modules/? This might not be an issue (can't check right now), but in case it is, then this should only be considered as a part of a bigger update, as it's a breaking change.

Related to links, I would also consider adding an underline – or some other obvious visual feature – to links. It's a little thing, but can make a notable difference in terms of accessibility: colour should never be the only thing separating text elements. Same thing goes for things like menus, i.e. active state shouldn't be communicated using colour alone ? Keep up the great work! Looking forward to featuring PW Review in the Weekly. How I wish that clients would sometimes say this too... ?

I've been using a very similar solution at weekly.pw, i.e. indexing data into a field called "search_index". The content is mostly built using PageTable, and I'm indexing content from those for the parent page's search_index field as well. No Repeaters or RepeaterMatrix fields here, but they'd require similar processing. The whole solution is built into some methods placed in /site/init.php. Might be useful for someone, so here's the code: https://gist.github.com/teppokoivula/83036c6e73d7460be7706def620d80d4. Note that in this case I'm not using the same index as an excerpt, but rather the summary field of the page. Excerpt would be better – will probably add them at some point. Once you have the index at hand, it's relatively simple ? Another thing to note here is that I'm currently using the same index field to store links in link:url format. Since tags are stripped from the index text, URLs wouldn't otherwise be a part of the index – and this also allows me to perform specific link queries, such as https://weekly.pw/search/?q=link:https://modules.processwire.com/modules/sanitizer-transliterate/ ?

Hi there, That's somewhat odd question to post to a support forum dedicated ProcessWire, a PHP based CMS/CMF – but no worries, here in the Off Topic area all questions are fine ? Personally I've not used Redux that much, but have you already checked their own tutorials? The basic tutorial (https://redux.js.org/basics/basic-tutorial) and the advanced tutorial (https://redux.js.org/advanced/advanced-tutorial) should give you a solid understanding of Redux.

Moderator note: this is not a support board for a new module, so I'm moving it to the General Support area of the forum. The "Modules/Plugins" section of the forum is for dedicated module support threads. If you have a general question regarding ProcessWire, ProcessWire core modules, or "how to do [x] with ProcessWire", you should post it to the General Support area – or if it's a question regarding an existing module, check the "Support Board" link from the modules directory entry for that module and post your question to the linked thread instead. Thanks!

Moderator note: this is not a support board for a new module, so I'm moving it to the General Support area of the forum. The "Modules/Plugins" section of the forum is for dedicated module support threads. If you have a general question regarding ProcessWire, ProcessWire core modules, or "how to do [x] with ProcessWire", you should post it to the General Support area – or if it's a question regarding an existing module, check the "Support Board" link from the modules directory entry for that module and post your question to the linked thread instead. Thanks!

Moderator note: this is not a support board for a new module, so I'm moving it to the General Support area of the forum. The "Modules/Plugins" section of the forum is for dedicated module support threads. If you have a general question regarding ProcessWire or "how to do [x] with ProcessWire", you should post it to the General Support area – or if it's a question regarding an existing module, check the "Support Board" link from the modules directory entry for that module and post your question to the linked thread instead. Thanks!

Can you access any other pages? If not, there's very likely some sort of an issue with your .htaccess file, or rather an incompatibility with your server and the .htacecss file. The 404 error message you're seeing also sounds like the plain text version from server, not a 404 page from within ProcessWire – so most likely rewrite rules configured in the .htaccess file are not working as expected. Might also mean that something is missing from the server, though if you just ran the install process, that should've flagged any such issues. In a bit of a hurry, but at least the .htaccess file is where I'd start digging into this.

Saturday morning I wrote in the the latest weekly issue this: And here's the view from my front door just now, Tuesday morning: I'm not particularly superstitious, but kinda feels like I dropped the ball on this one. To my defence, on Saturday there was literally zero snow here, and the whole day was sunny and warm and all. Proper shorts and T-shirt weather. I guess the lesson here is that it's always too early to say that the winter is over. Have a great day, folks!