teppo

Exactly what I was about to suggest too 😄 Dropdown sounds nice for some use cases, but in my experience what many/most users really need when building page content from blocks is some way to visually identify what each block is/does. (From that link Ivan posted, I gather that an easy hook to facilitate this already exists, or at least is on its way?)

Seems feasible. Depending on how it's done, just switching $pages->find() to $pages->findMany() can help a lot (assuming it's a relatively new PW). Recently worked on a site with ~700k pages, and making this change to SchedulePages helped speed things up considerably.

This is a bit vague, but Tracy can sometimes help identify slow requests. You could also look into browser dev tools (just in case it's some specific resource that's slowing queries down), slow database queries (MySQL slow query log if it's available, though PW debug mode tools can also provide plenty of insight into these if you happen to run into a slow query while browsing the site), and perhaps even Apache logs to identify which specific requests are taking a long time. If you have access to ProDevTools package, I can highly recommend Profiler Pro. We recently used this to debug a module that was causing issues due to hooks, and for that purpose it was brilliant. On the other hand: if said slowdown is indeed quite random, one potential culprit would be LazyCron. I would likely start by checking if any local code snippet or module is triggering a slow task via Lazy Cron. I've ran into that many, many times.

What's the value of upload_max_filesize in php.ini, and is your web server Apache or nginx? Asking because... upload_max_filesize limits the maximum size of any single file (post_max_size is the maximum size of entire request), and if you're running on nginx then there may be other directives (such as client_max_body_size) that also affect this. Depending on server config this may not work at all. If you have access to php.ini, that's definitely more likely to work.

Been using joker.com for domain registrations and (for the most part) DNS for a decade or so, and so far they've never let me down. Admittedly I don't know exactly how their prices compare to other registrars. Edit: actually it looks like my first joker.com domain was registered 17 years ago, give or take a few weeks. Not that it matters much; the gist is that I've been their client for a while, and they've always offered quality service 🙂

This sounds amazing! The forum search has always been a bit unhelpful (to say the least) — if this will make it better overall, it's a welcome addition 🙂

Technically it's a (browser rendering engine / HTML) feature, not a bug 🙂 According to HTML spec you can only put phrasing content within <p> tags, and as such, <div>'s are not allowed. When you inspect the page with dev tools, what you see there is the browser doing its best to convert invalid HTML markup into something valid (even though the end result is clearly not what you were aiming for). On the other hand when you're viewing the "raw" page source, browser won't try to parse or process it, which is why it seems to be fine. If you need an element within <p> tag to behave like a block element, you should rather use a <span> (or another inline element) with "display: block".

Agreed. Biggest benefits you get from using an external mail service are a) ease of use — which is largely a non-issue for ProcessWire users, since WireMail modules provide a consistent API — and b) confidence that someone else is making sure that your emails are sent, can be received correctly, and don't miss their target or end up in spam. With hosting your own SMTP server there are always potential gotchas, but again if you're on top of things they can be (mostly) avoided. When I say "mostly", I mean things like someone reporting your message as spam, which could become an issue for you. Not much you can do about that, really, except for making sure that your recipient list is full of folks who really want to receive your newsletter 🙂 In addition to what Horst mentioned above, I would recommend using a service such as https://www.mail-tester.com/ to make sure that your messages are a-OK before sending them to actual recipients. Edit: one ProMailer-specific benefit for using external service is that this way you can easily handle bounces and spam complaints etc. ProMailer supports webhooks for this stuff. You can set up a webhook for these without external service as well (at least for bounces, not entirely sure about spam complaints), but it could get tricky 🙂

Hey @Zeka To be honest what you're currently doing sounds like a reasonable solution, and also goes beyond what I've personally ever done/needed. In most projects I've got a handful of components — I think around ten or so at most — so splitting them into directories hasn't really been worth it. Boils down to preference, really; I tend to use partials for most things, and components only when I really need the power (and complexity) they add 🙂 So, long story short: there's no built-in way to split components into directories, but that's not a bad idea (after all that's always been there for partials), so I've added it to my list for now.

ProcessWire will generate directory-specific .htaccess files automatically unless a) they already exist or b) it doesn't have write access to these directories. While access restriction is what I'd recommend as a general best practice (in my opinion the system should never have write access to anywhere it isn't strictly necessary), that may require more tweaking than you're ready to go through. This leaves us with the first option. You could achieve this by making sure that you have empty .htaccess files in following directories: /site/assets/ /site/assets/logs/ /site/assets/cache/ /site/assets/backups/ /site/templates/ /site/ /site/modules/ If the files are empty, they should not affect anything, so... problem solved 🙂 Note that the reason I was asking what the path of the file is is that if .htaccess files in question are blocking access to it, there's likely a reason for that — i.e. it's in a directory that isn't supposed to be directly accessible. It would be best to check where it is, and why it is there in case that turns out to the problem.

Is this on the front-end of the site, or in the admin? I'm assuming it's in the front, but just making sure 🙂 If you check your browsers dev tools, is there any clue about it? Is your CSS file loading correctly? If not, what's the URL/path for the file, i.e. could it be something protected/blocked by the system?

This is an interesting dilemma for sure 🙂 Indeed components are rendered when their render methods are called (or they are converted to strings via __toString(), which then calls the render method), so they can't easily handle this type of logic. At the moment I think the easiest solution would involve placing some sort of tag in the layout which then gets replaced (likely via a hook) when markup is already rendered. This may not be what you're looking for, but here's how that hook could work: $this->addHookAfter('View::render', function(HookEvent $event) { $event->return = str_replace('{{ head_component }}', Wireframe::component('Head'), $event->return); }); (Bundling this into a component is of course not really necessary at this point. Also: if you do this, you'll likely want to check if wire('siteJS') etc. exists before setting it, since wireframe.php may get executed multiple times.) Another option would be pre-rendering your components in wireframe.php or a controller class for a template and passing them to Wireframe::render() as arguments. Depending on the use case this may or may not make sense; I've used that approach on some occasions myself. I tried a few other things, but right now I don't have anything more sophisticated than this. One idea I played with a bit that could solve this was similar to Blade components (<x-head arg="value"></x-head> etc.) but this comes with some limitations, so not sure yet if it makes sense... or perhaps we should have a way for components to specify methods that then get executed automatically later with predefined arguments? Anyway, I'll keep this in mind and let you know if I figure out a better way 🙂

As netcarver pointed out above, the amount of users is not going to be a problem. One site I've worked on recently has ~25 thousand users, most without admin access (just to a members area and a discussions forum), and that setup works just fine. One thing you need to take care of is that you don't grant said users' role/roles any admin-related permissions. Additionally if your site has front-end features that these users are not allowed to access, you'll want to make sure that you don't rely on $user->isLoggedin() alone, but rather always check that the user has expected role or permission. If you mean rolling your own system for handling all aspects of user management — authentication, authorisation, etc. — then I would recommend against it. ProcessWire has a solid system for handling such needs built-in, whereas any custom-built authentication solution would be a major security hot spot. In case ProcessWire's built-in system won't cut it for some reason (which I highly doubt), next best option would likely be using something like Laravel (or another application framework with proven track record) for this part.

So... this is not a big deal by any means, but I do wonder if it might make sense to split Adminer into a separate module — one that integrates with Tracy Debugger, if installed? I get that Adminer is behind some pretty high fences here, but still. It's likely to raise some red flags, at the very least. And yes, personally I would choose to leave Adminer out, if it was possible without losing all the other goodies I get from TD. Obviously that would be a big change, so perhaps something to consider in a future major release. Or not. Just saying 🙂

If you're just looking for a solution for the "email server sends email" part: Mailgun. Or any other API based service, really. Personally I've just about had it with local servers or SMTP setups. Obviously just my opinion, but I find email sending services way easier to work with, especially if you ever need to work with email related webhooks, check out from the email server/service logs what's actually happening/happened, etc. 🙂 (Mailgun used to provide a free plan, but now it's 5000 messages for 3 months and after that a small cost. I'm still using it on my own projects because $0.80 / 1000 emails is, in my opinion, a pretty good deal.)