teppo

Same thing here. Perhaps all foreign (or european or extracontinental or something) traffic is automatically blocked? (Which of course might be a good idea if the site gets a lot of traffic and actual users are very likely local...) Either that, or there's a slightly overprotective set of rules in place ?

Hey @stanoliver. Are you trying to render the snippet on the front-end only for logged-in users? If so, I've just added an option for that to the latest version of the module (1.4.0). Users to render the snippet for (all, logged in, or non-logged in) can now be selected via snippet settings. Let me know if I misunderstood your question, though ?

Agreed, this is kind of annoying. I don't run into this too often nowadays since I tend to keep only those files open which I currently work on — and usually all of them are visible at the same time, with the editor split into 2-5 columns/rows — but your suggestion makes sense to me. I'll look into this ?

Thanks for the clarifications, Ivan. At the moment the <?= $partials->sublayouts->sublayout_name() ?> approach is probably the closest alternative one to what you've been using. Or, alternatively, you could split common parts of the layout to partials, and include those in two different layouts, leaving out the layout/sublayout separation altogether. That being said, I just mocked up locally a setup where layouts can be embedded within layouts. This is probably even closer, though I feel like it needs a bit more polish and testing ?

Not sure how common this sort of practice is, but we always define custom colours for each project — usually with generic names such as brand-1, brand-2, etc. (unless the client has named colours or a lot of colours, in which case more specific naming helps). In fact in most cases I only use two colours from the default palette: black and white. Everything else (including shades of gray) are either custom colours, or just black/white with specific opacity applied ? Same thing goes with paddings: while we use the default spacing scale, there are always a few "project specific" values; half, single, double, triple, etc. Usually these are pretty straightforward (single = 1rem, etc.) but sticking to predefined, named values does make it a tad easier to make changes later. I don't think there's a built-in way for this. Depending on the specific use case I'd probably pick one of two options: If it's just a few colours etc. that need to change, add those to the shared theme config file for the site and handle the "colour theme" in code. If there are a lot of changes and/or for some other reason you want to clearly separate styles for different parts of the site, create a separate Tailwind config file and adjust your build process accordingly. How that would work depends on what kind of build process is in use, but generally speaking it shouldn't be too difficult ? If you google something like "tailwind multiple themes", you'll probably find other solutions as well. I've never needed this type of functionality, so haven't given it much thought.

I've been using Tailwind for years, yet there are still both those days that I really enjoy using it, and others when I wonder if it really makes sense, so I get what you're saying. Also: even though we use it for just about all of our projects nowadays, we often combine it with "custom" CSS classes (mostly BEM style), simply because Tailwind isn't always the correct tool for the job ?‍♂️ Others have probably said it already, but for me/us the benefits of Tailwind boil down to... super fast development, particularly when mocking things up / designing in the browser, common set of tools and guidelines, which is very nice when working in a team (having to dig into an older project that doesn't use Tailwind is a bit of a pain), and superb efficiency — by which I mean that using Tailwind results in very small CSS files, in most cases much smaller than I would get by writing my own vanilla CSS. There are a couple of things I'd view as downsides: a) markup becomes entangled with styles, and b) sometimes it feels like I'm just learning alternative ways to do the stuff I would already know how to do with vanilla CSS. First one is something that, in my opinion, can't be completely avoided, but using components for shared sets of classes helps a lot. Second issue becomes less of an issue day by day. Other than that, I'm quite happy with Tailwind, and it suits my workflow very nicely. It's not the perfect fit for everyone (or for every project), and that's fine too ? "What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking?" Well, we use a combination of custom CSS and Tailwind already, but the literal "layout" part is one that's actually so efficient to do with Tailwind that I wouldn't bother doing it in vanilla CSS anymore. In my experience changes to the layout are often easier to implement with Tailwind than with vanilla CSS, and the resulting markup is actually quite clean. "Having said that, how many percent of all the available tailwind utility classes are really going to be used?" It doesn't really matter how much of Tailwind I / we use. Thanks to the tree shaking logic the "compiled" result only includes what is necessary. There's zero overhead in having a large toolbox but not using each tool for every project. "That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap and bring them in your own utility class framework. That would make things certainly more effective." Exactly how would this make things more effective? We're in the business of building custom sites and/or applications, so pre-built components offered by a front-end framework won't help much (if at all), at which point — from my point of view — all Bootstrap and likes can offer is a very limited set of utility-first tools. Sure, we use prebuilt tools elsewhere (Vuetify for PWA apps etc.) but for custom-built sites Tailwind is (IMHO) a better fit.

Just a quick heads-up: https://tailwindcss.com/blog/tailwindcss-v3.

Hey Bernhard! First of all: congratulations, this looks and sounds like a brilliant project. And thanks for sharing all those details, always love to hear how things were actually solved ?? Your site search is something I'm curious about, so hoped you might shed some light particularly into the part about sorting. How did you go about that? Do you store the index content on PW fields, or do you have a custom data structure? Do you trigger multiple queries behind the scenes, or did you manage to handle sorting in a single query, in the database? Any SQL involved? Asking partly because this is a kind of a long standing issue / todo item for the SearchEngine module. Weighing is relatively simple to do with custom database tables / queries (or rather there are existing formulas for that), but with selectors... well, it's tricky. By which I mean that I haven't been able to figure it out yet without a) custom SQL queries or b) expensive in-memory operations. And yes, I'm kind of fishing for good ideas here... ?

If I got this right, you've got a three-layer approach (layout - sublayout - view) instead of Wireframe's regular two-layer design (layout - view). If so, this is not really something I've had much need for before, but here are a couple of rough ideas: If you have, say, "single column sublayout" and "two column sublayout", you could include the content that you'd usually put into these directly in the main layout file, accompanied by some sort of switch. For an example you could pass an argument to the layout via the bootstrap file (or from the Controller class), stating which sublayout you want to use for current page/template, and then just include related if statement in the layout file. This is, of course, not a very clean solution if sublayouts differ a lot from each other. But if the differences are minor and/or sublayouts are relatively simple, then introducing a whole new layer might be overcomplicating things a bit. You could use partials: instead of directly including <?= $placeholders->default ?> in your layout file, you could call <?= $partials->sublayouts->single_column() ?> etc. and thus mimic that extra layer. Of course this still requires some method of defining which sublayout to use for each template or page. Now, one thing I don't fully grasp is that how do you decide which template(s) use a specific sublayout? If I knew that, I might be able to suggest better solution. Would also be interesting to hear a bit more about what exactly is in the layout vs. sublayout. This might be something that we could support in Wireframe right out of the box — though before that I'd like to fully understand how it should work, and what is / what are the problem(s) it solves ?

Hey Bernhard. Just to confirm: do you mean that the corrected image rotations array didn't fix the issue for you? If so, did you have client side image resizing enabled, and did you try if disabling that makes any change? PM'd.

The link abstraction part sounds a lot like https://github.com/processwire/processwire-issues/issues/1244 to me. Just cross-linking for reference.

Hey @horst — sorry for pinging, but I'm pretty sure you're most likely to know what's going on here ? So, I've been having similar issues with one site, where there are a lot of profile pics etc. Quite often uploaded images are not correctly rotated by ProcessWire. It's not super common issue, but common enough to cause major problems for admins. Now, one pic which I'm currently testing (I can share a link if it's important) reports EXIF orientation as 8: Based on our built-in corrections array, orientation 8 should be rotate 90 degrees (clockwise, I presume). Based on some other sources, such as https://www.impulseadventure.com/photo/exif-orientation.html, orientation 8 actually requires 90 degrees CCW (or 270 degrees CW). Am I reading that source wrong, or is there a mistake? The array provided by @bernhard fixes the issue for me, and seems to be in line with at least that single source. I am not well versed in this topic, so be kind; I may be entirely missing the point here ?

Hey @Ivan Gretsky No reason whatsoever — probably just forgot. Submitted ?

Hey @B3ta — thanks for the suggestion. Just to confirm: are you talking about a feature that would clear the built-in template cache for current page, or perhaps the entire site — or something else entirely? This sounds like a useful option, but there are a few variables here, such as whether one uses the native template cache or ProCache, and whether this option should clear cache for all pages or just current page. As such, I'm not yet sure if this could/should be added as a built-in feature to the module.

Sure thing — links updated.

While the first link provided by @Ivan Gretsky seems like a good starting point for creating forms with InputfieldForm, note that this is not exactly the simplest thing to do. Personally I've never found it very intuitive, or very useful for that matter. (This, of course, is a highly opinionated statement — so take it with a grain of salt.) In my opinion it's almost always easier to just create a basic HTML form: <form action="." method="POST"> <label for="your_name">Your name</label> <input type="text" name="your_name" id="your_name"> <input type="submit"> </form> ... and then process form input in the template file: <?php namespace ProcessWire; if ($input->post->your_name) { // always sanitize user input (https://processwire.com/api/ref/sanitizer/) $your_name = $sanitizer->entities($your_name); // do something with input echo "<p>Hi " . $your_name . "! What's up?</p>"; } Of course that's a super-simplified example, but hope you get the point. Using InputfieldForm, InputfieldText, InputfieldSubmit etc. is doable, but in many cases they mainly just add a whole new layer of complexity without much actual benefit ? If you want to save values to custom database tables, you need to work with "raw" SQL through the $database object. But here's the kicker: The preferred way to save data in ProcessWire is through pages. A "page" is essentially a general purpose data storage object: you can use pages to store publicly viewable (front-end) content, as well as (back-end only) categories or tags, or form entries — or really whatever it is that you need to store. The API is largely built around working with pages: creating, finding, reading, modifying, and deleting them. Again: you can work directly with database tables through the $database object, but that's not really what ProcessWire was built for. (It's useful for special situations, but for a beginner that's not what I would recommend starting with.) As such, likely the easiest way to save data would be to create a template with fields related to your entries, and then on each form entry creating, populating, and saving a page using that template. That's not necessarily scalable if you expect tens or hundreds of thousands of entries in a short period of time, but apart from that it will work just fine ? ... although, to be fair, a lot of folks just use Form Builder for building and managing forms. It's a commercial module, but in the long term it saves so much time and makes things so easy that it's well worth it. Especially if you're working on projects that you get paid for. This depends on the context: if you're writing code in a template file (/site/templates/some-template.php) then you can use $modules. If you're writing code within a class that extends the Wire object — module, Page class, etc. — then you need to use $this->modules instead. And if you're writing code within a module, you generally use wire('modules'), etc. Here's a docs page explaining when to use what: https://processwire.com/docs/start/api-access/.

This is also more or less what Gutenberg does by default, in two slightly different ways: hovering the block before selecting it brings up a live-rendered preview (based on placeholder data provided by the block), and once the block has been added to the page you can switch it between edit/preview mode (assuming that said block has not enforced a specific mode). Preview-on-hover was something I had planned to experiment on based on the newly added hook(s), but preview mode (similar to PTE or ACFE) would be neat too ?

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 ?