teppo

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 🙂