Jump to content

teppo

PW-Moderators
  • Posts

    3,208
  • Joined

  • Last visited

  • Days Won

    107

Everything posted by teppo

  1. 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.
  2. 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/.
  3. 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 ?
  4. 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?)
  5. 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.
  6. 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.
  7. 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.
  8. 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 ?
  9. 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 ?
  10. 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".
  11. 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 ?
  12. teppo

    Wireframe

    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.
  13. 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.
  14. 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?
  15. teppo

    Wireframe

    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 ?
  16. 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.
  17. 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 ?
  18. 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.)
  19. teppo

    Wireframe

    Does this mean that you've got the __text() call directly in the template file, site/templates/sometemplate.php? If so, then it's likely the issue I mentioned in my previous post: if you use functional fields in any file other than the default template file, you'll have to select that file via field config "file mode" setting.
  20. I'm running a couple of 3.0.165 sites on MySQL 8, and so far there have been no issues. On a loosely related note: in case there are any third party modules installed that make direct SQL queries, be sure to test those as well.
  21. I am by no means an expert on this area (IANAL etc. ?) but this is worth checking out: https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2847. While privacy shield is no longer applicable, standard contractual clauses still are. As such, I wouldn't completely rule out a company with non-EU presence. Most email service providers have comprehensive GDPR info available, and most of them also seem to provide a DPA (data processing agreement/addendum) for their clients, at least on request. Anyway, just my five cents. Of course when in doubt, it's a good idea to consult lawyer. Preferably one with experience in GDPR and Internet privacy ?
  22. teppo

    Snippets

    Thanks for the report, @wbmnfktr. The page list option was misbehaving, this is fixed now in the latest version of the module (1.0.2).
  23. teppo

    Wireframe

    That's a strange one, unless of course the namespace declaration wasn't the very first thing in the file, right after the first PHP open tag. It should work fine in view files — in fact I always add the namespace to view files, just in case ? Calling the method via ProcessWire namespace is fine, just a bit verbose. My guess: you'll have to modify the "file mode" setting of the functional field, selecting your view file(s) there. By default functional fields is set to look for function calls from the template file, which means that it won't show up in the editor if it's placed in any other file, including files included/required from the template file etc.
  24. teppo

    Wireframe

    We can rule the missing field issue out, so next question: does your view file have the ProcessWire namespace? If not, try adding it. Or refer to the __text() method as \ProcessWire\__text().
×
×
  • Create New...