teppo

Here's another example from the VersionControlTests package: https://github.com/teppokoivula/VersionControlTests/blob/master/tests/VersionControlTest.php#L170:L179. It's in a PHPUnit test class so the syntax is a bit strange, but at least the last time I ran the tests this worked (though that was against PW 2.x.)

Sadly I don't have an answer to the issue raised here, as I have only just started to play with ProcessWire and Docker, but I've got a very similar setup on a MacBook Pro (4 GB RAM and 6 CPU) for WordPress development – and I have to say that it's often painfully slow. This does seem to be a relatively common problem, at least for Mac users. That being said, I'm running a fairly non-standard and complex WordPress stack, so it may strictly speaking be something other than the WP core which is the root cause – ACF or any of the other plugins, something in the theme, etc.

Thanks – I can see definite improvements already, and we can surely keep improving things after the initial launch as well! Regarding the target group I get what you're saying, but it's good to keep in mind that improved accessibility actually benefits us all – it's not (just) about catering for users with disabilities ? "While accessibility focuses on people with disabilities, many accessibility requirements also improve usability for everyone. Accessibility especially benefits people without disabilities who are in limiting situations, such as using the web on a mobile phone when visual attention is elsewhere, in bright sunlight, in a dark room, in a quiet environment, in a noisy environment, and in an emergency." (W3C WAI) My eyesight is way below average, and I can see a lot of artefacts and other signs of low quality in there. Just checking, but do you have a retina screen? Could be somehow related to resolution as well – I've got a 15" MacBook Pro with resolution set to "scaled" and "more space" set to the maximum value.

+1, forgot to mention this one. WCAG AAA requires that line length is never more than 80 characters, but depending on the source comfortable range can be around 80..100 characters, and sometimes as high as 120. Anything above that is way too long considering readability, and I'd recommend not going past the 100 character (or glyph) mark.

+1 to giving contrast more consideration. Overall the site could use a bit of brushing up in terms of accessibility – some quick observations: Providing a skip to main content link would be nice, and while we're at it, providing another one for certain long lists of items (such as the showcase items) could also be a good idea. At least on the home page the logo icon and the text next to it are separate links, but still lead to the same location – I'd recommend hiding one of them from keyboard / screen reader users. There are no focus styles for the top navigation, so keyboard navigation feels quite strange; the cursor seems to simply disappear somewhere. The search icon doesn't seem to have label for screen readers to read, so it's just "link: newsite". Same thing with the close icon for the search. One more keyboard navigation issue occurs once I reach the showcase section: again the cursor disappears, and I actually have to browse all items (even though visually nothing changes on the screen) before it reappears. This might've been mentioned already, but I for one keep getting the "home" link wrong, since (in some cases) the text link right next (which is visually connected to the logo and thus I would've expected it to lead to the home page as well) takes me somewhere else. This is one of those "oh, I see what you did there" cases: now that I've clicked the wrong link a couple of times I know how it works, but surprises like that don't exactly improve the overall experience ? Additionally I find it very confusing that the navigation hierarchy doesn't match content structure. For an example, if I choose "Docs" > "API Reference" from the navigation, I'm suddenly taken to another area of the site – and probably for that reason there's also no indication about where I currently am in the top navigation, since this new area isn't included in the navigation, even though it's hierarchically a top level page. Finally, I would recommend adding some sort of indication to navigation links that take the user out of current site. "Community" for an example is (a bit weirdly, in my opinion) linked to the Forum, which may come as a surprise to the visitor. I've always instructed clients to never, ever link to another site from their top navigation – but if we really have to do that, at least we should make it obvious what's happening ? .. and all that said, this is definitely an upgrade to the old site. Sure, there are rough edges, and I must agree with a lot that has been said in this topic, but I'm sure we'll figure it out. Great job, Ryan!

As a one-off example of putting Sanitizer to work, I'm currently working on a module in which I convert template names to pascal case class names, so recently added $sanitizer->pascalCase() came in handy there. On the other hand, $sanitizer->pageName(), $sanitizer->selectorField(), and $sanitizer->selectorValue() are probably what I've used the most. Even if I know that ProcessWire has some sort of validation built-in, I much prefer to filter data before passing it to ProcessWire: not only does this provide an extra layer of safety, but it also allows me to display more helpful error messages to the end-user. $sanitizer->option() and $sanitizer->options() are also useful. They're basically shortcut methods to whitelisting values, and who doesn't need a whitelist every now and then? Some Sanitizer features are more about formatting, really: $sanitizer->truncate() is a good example of this, as it's basically creates excerpts of longer text. Definitely useful. All in all, it really depends on what you're doing with ProcessWire, where you're getting your input, and so on. If you're handling raw user input a lot, Sanitizer is particularly useful. Similarly if you tend to enforce more specific rules for your data (say, only allow specific values, or specific characters, etc.) you can get a lot out of Sanitizer. Personally I'm also a firm believer in the "defence in depth" practice: can't have too many layers of protection ? By the way, in your code you mention that Inputfields run Sanitizer methods. It's probably worth noting that Inputfields won't interfere while you're storing data over the API, and thus they won't prevent anything from being saved to the database either. Fieldtypes handle data storage, and Inputfield settings kick in when you edit that value in the Admin.

First of all, I would recommend reconsidering your approach. ProcessWire's built-in admin is quite user-friendly, and building essentially the same thing on your own sounds like a lot of effort that you could use for something more beneficial. Not to mention that you'll have to be pretty careful to avoid any permission related issues etc. – all in all not something I would recommend unless you've got a really good reason for it. The answers to your questions, if you still choose to go this route, would depend on your needs: do you have multiple types of users with different fields, or are they all the same? What will these users edit – their own profile page, or something else? If it's their profile page, should it be publicly viewable? If not, how are you planning to control access – on a page by page basis, or based on groups, or something else entirely? ProcessWire supports multiple parents/templates for user pages, so that might be something you could look into: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users. Hope this helps a bit.

$config->httpHost should return current domain (if it's included in the httpHosts setting) or the first domain from said setting if no match was found. Here's the related code for reference: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/ProcessWire.php#L308-L323. If you're accessing your site with the dev domain and this domain is included in the httpHosts setting, that should be what this method returns. If not, I'd make sure that related settings are properly configured, and that your server works as expected (particularly in terms of SERVER_NAME and/or HTTP_HOST). I'm not entirely sure what you're referring to with the "edit multiple URLs in the code" part, but generally speaking I'd recommend using relative paths etc. instead of fully qualified domains. This way it doesn't really matter which domain you access your site from. It's possible that you were actually referring to something else, so feel free to clarify this part ? Edit: actually there's one more thing to keep in mind here, which is that ProcessWire prefers the ServerName value from the Apache VirtualHost block ($_SERVER['SERVER_NAME']) over the host header provided by the browser ($_SERVER['HTTP_HOST']) when determining httpHost. ServerName is used at least if Apache "UseCanonicalName" setting is "on", but this behaviour may apparently vary between different Apache versions. In this case the solution would be either disabling the UseCanonicalName setting, or creating separate VirtualHost blocks for all domains you want to use with ProcessWire.

That isn't actually necessary; Process module execute methods don't have to be hookable. (Gadgetto, in case you haven't yet looked into the hook system, three underscores are only required if you want to make the function hookable – i.e. allow code in template files, modules, init.php / ready.php files within site directory, etc. to "hook" into their execution. Otherwise it's fine to leave them out.) On a loosely related note, you also don't have to set up your own PHP version comparison. You can define required PHP version with the "requires" setting ?

Sorry to answer a question with another question, but is there a specific reason you want subscribers to be users? You mentioned being able to use the MODX permission system, but what do you use it for? While there's no technical reason why you couldn't make your subscribers ProcessWire users, the reason I'm asking is that unless there's a solid reason for it, I'd recommend not going that route. You'd essentially have to build an open registration system, where anyone can create new user accounts. While that isn't necessarily a problem in itself, coupled with any kind of permission related issue things could get very ugly very fast. That being said, depending on your needs you could use users, or you could create a custom template for your subscribers, or you could even create your own database table(s) – though that last option would likely not be preferable, considering that you wouldn't be able to benefit from ProcessWire's API. Whether you go with a custom template or choose to build upon built-in system users, I'd recommend looking into $pages->findMany(). Thousands of users / pages shouldn't be an issue.

I'm not sure if it's still applicable, but there's an old module as well: https://modules.processwire.com/modules/pageimage-remove-variations/. Although I'm guessing that @horst already knew about it... ?

Old discussion, but yeah – the plus sides of this kind of naming are that 1) it's a common practice across different systems (which makes it easy for new devs to grasp), and 2) that it's a very commonly typed function – not to mention one that you often see in front-end (or "view") part of a site or an app, and thus it's good to keep it nice and short . Expanding on the second point a bit, in the view side it often makes sense to have short function names, even if they're not particularly descriptive. Think of PHP's short echo tags (<?= ... ?>) or various tags implemented by templating languages: the point is to create minimal clutter, thus keeping view files clean and easy to follow ? --- Note: this thread is not related to module development per se, so I'm moving it to the Getting Started area of the forum.

Admin note: since this is clearly not a support thread for a module, I'm moving the whole thread to the General Support area of the forum. Please note that Modules / Plugins is only intended for dedicated module support threads. Thanks!

To be honest I'm a bit confused by your question (for an example I have no idea what you mean by "referring to mydomain/index.php" and how this relates to ProcessWire), but if you're trying to read a GET variable (mydomain/?u=value) in one of your template files then you can access it via $input->get->u. You can use $_GET['u'] as well since $input is mainly just a wrapper over GET / POST / COOKIE, but I'd recommend using $input in the context of ProcessWire ?

Admin note: I'm moving this thread from the "Modules/Plugins" section to the "General Support" area of the forum. Please submit general / core / core module related questions to the General Support section instead of Modules/Plugins.

@ryan, any chance you could set up a support forum thread for LoginRegister? Currently it doesn't have one, and these requests pile up in the Modules/Plugins area. Just trying to keep things nice and tidy here ?

Note: I've just moved this thread from the "Modules/Plugins" section of the forum to the "General Support" section. "Modules/Plugins" is intended for dedicated module support threads, and general questions like this belong to other areas ?

Browse to madewithlaravel.com and check out pretty much anything that doesn't manage data, and/or doesn't produce output. From the front page: Clockwork, Fractal, Vessel, etc. Also anything that is more "component", intended to be used within other applications, rather than a "full-blown application" itself ? Perhaps a more familiar example would be wireshell.pw. While it's not built using a WAF, it does make use of Symfony components. Could it be built using ProcessWire? In theory yes. Would it benefit from being powered by ProcessWire? Not really.

What @LostKobrakai said. The short answer to "what can Laravel and Symfony do that PW cannot" is "nothing", but in my opinion that's not really the question you should be asking – rather you should ask what it is that they are better suited for than ProcessWire ? In my experience (based on other web application frameworks, not Laravel or Symfony specifically) the biggest day-to-day difference is exactly the general purpose nature of web application frameworks: ProcessWire is specialised to content management, hence it's a "content management framework" (CMF) rather than a "web application framework" (WAF). In some regards ProcessWire has more built-in stuff than WAF's, and in some regards it has less – just like LostKobrakai pointed out above ? Some examples of the differences include routing and project structure / application architecture: Although this might be changing, not too long ago it seemed that every PHP framework enforced MVC pattern, or at least recommended it. ProcessWire, on the other hand, doesn't (natively) include anything like that. The default, out-of-the-box approach ("output strategy") is a straightforward solution where single template file contains (or rather can contain – of course you can also split it into multiple include files) all the code required by said template. Similarly in ProcessWire URLs are by default routed to pages, and although custom routing is technically possible using URL segments, there's no real, robust routing library included, other than what Pages / PagesFiles / Process modules require to function properly. While it's true that you can build pretty much anything on top of ProcessWire (or WordPress, or Drupal, or any remotely flexible CMS/CMF for that matter), whether that's a good idea depends on a number of factors. For an example, if there's no content to manage – or the content you have requires a very specific type of structure or storage mechanism or something – a general purpose WAF may provide you with more suitable tools than most CMS/CMF platforms ? Just for the record, https://madewithlaravel.com/ has quite a few examples of stuff built with Laravel. Some could've made at least as much sense as ProcessWire projects, while others are clearly better suited for a WAF.

Congrats on the new computer, Ryan. I'm assuming that this is related to moving onto the new dev setup, but it almost calls for one of those "yo dawg, we heard you like ..." meme pics, amirite? ?

Some extra overhead is to be expected, but it really shouldn't affect performance "massively". Hard to say more without seeing actual numbers and/or digging into the implementation, but first you should make absolutely sure that there's nothing strange going on: Check that there aren't any 404 requests due to HTTP/HTTPS mismatch. These can sometimes result in very noticeable increase in load times. Double check for odd redirects using something like Chrome dev tools: make sure that your HTTPS requests are not, for some weird reason, getting unnecessarily redirected. Make sure that your server isn't doing anything it shouldn't be doing when request is sent over HTTPS. This is a bit vague, but without knowing anything about your server, it's hard to narrow this point down either ? Finally, try to see if there are any third party dependencies (browser or server side) that could cause the delay. Regarding server side issues, you can find useful tips from the typical sources, such as Stack Overflow. This particular thread, for an example, mentions keepalive as a possible source of slowdowns. Although I find it hard to believe that someone would intentionally disable keepalive, that's definitely worth checking if the issue is very noticeable. Probably plenty of other stuff to check too, but to summarise: HTTPS is slower than HTTP, but the difference is rarely in "massive" scale ? Edit: if it wasn't already clear, I'd like to add that there's a very high probability that this issue is actually not about ProcessWire per se, but something else entirely.

Hey @MischaK, just wanted to say thanks for going through the trouble of explaining your findings here. Very much appreciated ? I'm also glad to hear that there's still demand for versioning the content. I originally developed the Version Control module when we were in the process of migrating from an earlier, in-house CMS to ProcessWire. Since our old system had extensive versioning system built-in I thought it'd be a necessity for the new system as well, but at this point I'm ready to admit that I might've been somewhat misguided. It's been years since that migration started, and so far I've had a handful of clients request some method of content versioning. The times I've had to solve an issue where content was accidentally removed and couldn't be found anywhere can be counted on fingers of one hand – and yes, we've dealt with some pretty big sites. Talking about dozens of content editors and thousands of pages of content. My conclusion at this point is that it's rarely a real necessity to have content versioning in a CMS, but you're absolutely right that it's a great safety net to have. I guess it's also more important (and more useful) for users that are already used to having it in, say, a system they've used before. Kind of like how you see devs build software without any kind of version control system in place: to me it seems like a horrible nightmare, but they don't know any better – and if they've been doing that for a while already, they've probably developed other approaches to versioning or backing up their work ?

@zoeck, it seems that you're talking about the issues caused by jQuery incompatibilities: currently the front-end editor doesn't play well with jQuery 3.x. That's a real issue, and it needs to be addressed. That being said, front-end editing is a difficult topic. That's one border case where ProcessWire really has to step into the "developer's domain", i.e. inject it's own features (scripts, perhaps even styles) into the front-end of the site. So far I think it's been handled relatively well, but it's no surprise that some issues are going to surface. I'd give it some time. We'll get there, eventually. Also: if you don't want the backend system (ProcessWire in this case) to touch anything at all in the front-end of your site, you should probably steer away from front-end editing altogether. As the name says, it's a front-end feature — and as such, using it is completely optional ?

Just noticed that ProcessWire is listed at the new RedBeanPHP website's "frameworks" page, with a link to this module: https://www.redbeanphp.com/index.php?p=/frameworks. On a related note I should probably update this module to a newer version of RedBeanPHP ?

Seems to me that built-in approach requires domains, which of course can be temporary/fake/local domains and not real ones. If you google something like "xampp custom domains" you'll find a few articles / threads on this, but general process involves editing your hosts file (whatever that is called in Windows) and adding these domains to Apache (via VirtualHost block somewhere, unless there's a GUI for this in XAMPP). Best practice seems to be using .test domains for local development, i.e. site1.test etc. ProcessWire doesn't care that much about which domain you use, so having multiple rules ('site1.test' => 'site', 'site1.com' => 'test') shouldn't be an issue, but alternatively you could add some kind of test (ENV?) to choose which domain to pick. ?