ryan

Teppo, good points. Though on the servers I work from at least, you'd need access to the server account before you could ever get into the DB. Though I know this isn't representative of all environments. In general, I think DB backups are where there's more potential need to protect things. Those might be downloaded to the developers computer and then become more independent of the server, where encryption could actually be a more valuable protection. Encrypting emails does seem pretty silly given their purpose, so it's not something I'd do unless I had no choice, but for people where that's the case the good news is that it would be very simple to do.

Thanks for your questions. I suspect that what they are really referring to with encryption has to do with using HTTPS, though I could be wrong. That's where encryption would matter most here. If they are instead referring to private storage of the data on a server/DB, then "user data" is probably too general a term. Things like SSNs or financial info would be confidential user data that you might want to encrypt with a user's password as the key, so that it would not be reversible except by the user. Things like an email address or website URLs probably not. That's because they are already public identifiers used by the internet as a network, passing through perhaps dozens of other servers on their way to their destination, and stored in non-encrypted logs by both originating and recipient recipient server. So if one is using some kind of confidential data as part of their email address, they probably shouldn't use it for... email. Storage of any data, whether confidential or not, is of course "protected" by the access control of the server. At the other end of the spectrum, if one can access data already, encryption doesn't add any protection if the means of reversing the encryption is located on the same server where the encryption occurs (as it would have to be to make use of it on a website). That's why I think that GDPR statement must be referring to HTTPS, since encrypting these things at the server side would require decrypting them at the server side, and thus wouldn't be very useful (false sense of security). Nevertheless, if it's something you want it do, it would be fairly simple to implement, and I'm happy to outline the hooks necessary to do it. The big drawback is that the data would no longer be searchable. But if one has the need for whatever reason, then yes, it's definitely possible A user can only receive a newsletter if they subscribed to it and also confirmed that they wanted to receive it by verifying their identity via email. So that could not be considered "unwanted" email since one has to specifically opt-in to receive it. However, if there are some kind of public blacklist services or lists that you want to use to prevent users from even attempting to opt-in to a newsletter, then I could definitely add support for them. I'm not aware of any at present, so if you are, please let me know and I can get a closer look. Though I'd think just the public existence of such a blacklist would probably invite unwanted email to those addresses, from outside the jurisdiction of the blacklist. ProMailer is not a tool for sending spam, and if that's someone's intention ProMailer is not the right tool for that. Regardless of tool, if someone can make false claims and subject someone else to $5k per email of penalties, then I would probably eliminate email as part of any business model in those jurisdictions. So if that's the case, email would be dead in my book and I'd move user communication to another medium like SMS or even traditional postal mail. You can only subscribe if you confirm it with your email address (double opt-in). So the only situation where you can subscribe is if you yourself confirm it from your email. You can test it out from here if you'd like. But if someone breaks into your email, then yes they could subscribe you. If that's a concern, then this is another situation where I would avoid email as a medium for communications. We do store the timestamp of both subscription request and confirmation. No IP addresses or information about the browser client are stored by default, but you can store the information on your own if you'd like to.

This week ProcessWire ProMailer has been released, plus we’ve got a nice upgrade in our community support forum, and more— https://processwire.com/blog/posts/promailer-now-available/

Glad you like the updates! Hope I didn't give the wrong impression, as I didn't intend to communicate anything about a "feature freeze" (as was stated in one of the messages above). At least nothing like that was, is, or ever will be planned, except maybe for a few days prior to a master version release. This is a stable project, but not a static one. There is no freezing or thawing, just the flow—I'll try to clarify... ProcessWire was originally built out of the needs of web development projects here, and that has always been a significant driver of what and when features are focused on at any point in time. When I add or improve something, it's usually because I'm going to be using it now and always going forward in actual projects, and by extension, can also support it in this project for everyone else. Of course, I only add/improve stuff that I know has significant benefit for all PW users, regardless of whether it's recognized in the short term or not. The other major part is features that arise from needs or contributions in the community here and on GitHub. My client projects are pretty similar to those of most PW users, which is good for the project. I'm always looking for ways to optimize and improve PW and its API, especially things that will save time in my and your projects, and this has always been the case. I'm driven by it. The feature focus is always holistic and never sacrifices backwards compatibility. And the product focus is on long term quality and sustainability, being the best tool for the job, not on being popular. The focus may largely be on issue reports right now, but this should not be interpreted to mean anything beyond resolving issue reports. I'm making continuous improvements and additions where appropriate along the way, as always. Perhaps they aren't big enough things to warrant blog posts now, but stay tuned — there is lots of good stuff on the way and currently in development. Every year there are a couple of important periods of good momentum in the issues repo, especially this time around, and so I'd like to continue that as long as possible and hopefully cover everything there. The difference this time is that we've got Netcarver expertly leading the effort as well as intelligently identifying which reports are still relevant. Plus there are a whole lot more "includes suggested fix" reports this time, thanks to people like Toutouwai and many others that know their way around the core extremely well, and often figure out how to resolve issues well before I do. It's a great community collaboration.

Just a quick update this week rather than a blog post. I’ve been continuing to work through the PW issues repo with Netcarver and it seems to be working well, so am planning to just keep working through it till we’ve covered everything there. Thanks to Netcarver and everyone else helping there. When we get the issues repo to the point where it’s pretty empty, I thought we’d then move on to the requests repo and PRs if possible. While there have been several commits to the core this week (mostly related to the issues repo), I don’t think there’s anything major enough to warrant a version bump, so will get another week’s worth of updates in place before bumping it to the next version number. This week I’ve been putting the finishing touches on the ProMailer module, getting that ready for release. A copy of ProMailer will be available to current subscribers of the ProDevTools package that want it. A few people have indicated that they’d also like to see it as a product independent of the ProDevTools, and actually I think that makes sense because ProMailer has become a much more comprehensive product than originally planned, and it really needs its own dedicated support board, as well as dedicated dev and agency versions. So I will make those available separately from ProDevTools. If you are a current ProDevTools subscriber and you’d like to get the first version of ProMailer when it is ready, please send me a PM here in the forums indicating that, and I will get a copy to you when it is released in beta. Even if you aren’t a ProDevTools subscriber, but would still like to be notified when ProMailer is available, please send me a PM as well. If all goes well, it should be available by this time next week or earlier. Next month we’ll hopefully be back to work on the website here as well, and develop the new modules directory.

@Autofahrn I don't really understand the code above well enough to know how to answer your question specifically, but one thing that jumps out to me is that you are interacting with POST data here, and that's something you want to avoid if possible. I looked in InputfieldPageListSelect and it doesn't have any getConfigInputfields() method of its own so I don't think it is adding anything here, instead, that method in InputfieldSelect is what you'd want to look at, particularly the part where it skips out early if the Inputfield isn't connected with a Fieldtype: if($this->hasFieldtype !== false) return $inputfields; . I would also try and use TracyDebugger with those bd() calls after your $cfg->set() to see what you are setting just to be sure.

Version 3.0.127 contains almost 30 new commits, the majority of which are focused on resolving older issue reports. For more details on those commits, see the commit log. This latest version on the dev branch also adds a couple of new features that you might find useful. Specifically, two new Page status flags: “unique” and “flagged”. Below we’ll go into more detail about what these are and how to use them. https://processwire.com/pw-3.0.127/

Repeater pages are just another type of Page so it should work fine to use the $page->if() when $page is a repeater item. Using an $page->if('repeater_field', ...) when $page is a Page that has the repeater field on it will also work since RepeaterPageArray is a type of PageArray. Though let me know if you were thinking of something different.

This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new $page->if() method— https://processwire.com/blog/posts/pw-3.0.126/

This week we take a closer look at the upcoming ProMailer module with a lot more details and screenshots. Plus an update on next steps with the new website and development schedule in the weeks ahead— https://processwire.com/blog/posts/promailer-preview/

@Robin S Good point, I need to update that phpdoc in that file and will. I think it'll be more convenient for users if I keep it up to date with Sanitizer, rather than removing it completely. At least I like my code editor being able to recognize them as function calls rather than errors. As far as I know, there's not anything we can do phpdoc-wise to cover instruction methods (like text50_entities), since there's basically an infinite possible combination of them. Though will be translating the blog post into regular documentation for these new additions.

Feel free to keep reporting here. I am checking in here for errors like this every few days and then fixing them as they come up. I'm guessing not too many more of these will turn up, as I've been continuing to update the logic in our 404 hook, plus logging 404s in ProfilerPro to catch any others that might have been missed.

ProcessWire 3.0.125 has several useful new $sanitizer methods and options, as well as new ways to access them directly from the $input API variable. This makes dealing with user input even easier than it was before. This version also brings updates to our translation functions and improvements to our API documentation: https://processwire.com/blog/posts/pw-3.0.125/

If you've got the Android File Transfer app installed, try removing it. After upgrading to Mojave here, I was getting constant disconnects on bluetooth, which might have been the same with WiFi. After several days trying everything, finally uninstalled Android File Transfer and then no more problems. Still missing having the convenience of that app, but it really was screwing things up. Surprisingly runs just fine on my MBP, though I've not yet upgraded that to Mojave, so that's probably why.

I'd planned on writing up a blog post today and bumping the PW version up to 3.0.125, but working on documentation pages ended up taking up most of the day. My hands are getting a bit tired from all the writing, so I'll keep this post short. ? I'll have a more formal post with more on the 3.0.125 version next week. People have been asking for more information on the various ProcessWire API access methods, as well as more information on the Functions API. I've written up a new documentation page that covers all the details. Though it's become a bit long, so next week I might split off the Functions API part into a separate child page. But for now, this is what I've got—the new documentation page is located here: https://processwire.com/docs/start/api-access/ In addition, the ProcessWire API Explorer module has been updated to support documentation for ProcessWire's procedural functions this week. And as a result, our online API documentation page now covers them all too. I spiffed up the phpdoc on all of them (and in some cases re-wrote the content) in preparation for that. For those that were asking for more documentation on the API functions, this page also has a section dedicated for those. Here's a direct link to our more than 50 procedural functions available in PW that previously didn't have any online documentation: https://processwire.com/api/ref/functions/

This is not what I'm saying. You seem to think this is something complex, but I think that's because you are used to something different. New users will not already be used to something. What I'm suggesting is actually much simpler than you think, and is more specific and clear than using exclusively $var or var(). Please wait and see what I write up this week, and I think it'll make sense. Like I mentioned earlier, if you fully understand it and still don't agree about the benefits, then I'll reconsider, but for now trust me on this. I would agree if we were showing $pages and pages() in the same set of examples, or $page and page(). But we are not. The examples don’t state “this is from a template file” or “this is from another script”, or any number of other contexts you could access PW’s API from. There’s plenty of cases where this call will work exactly as-is. If you are in a context where it won’t, it even specifically tells you what you need to do: call $page->of(false); first. Any 1-line example could work in one context and not another, that's the nature of it. In this brief set of intro examples it's important that we show not just getting data, but also saving it—wouldn't you agree? Yet setAndSave() is an advanced call, there for people that know what they are doing with regards to output formatting. It's not something to put in a beginner example because it's not for beginners. It’s important to learn what output formatting is before you start bypassing it. So I’m a little shy about a setAndSave() call here, plus I think it’s kind of a unique one-off in PW’s API, so not a general API example to communicate the underlying flavor of the API. And these examples are trying to communicate the overall flavor of the API, something to get you interested enough to explore further. In the examples we also refer to floors, height, year, email. Immediately under the examples it states “All fields in ProcessWire are custom fields that you easily define and edit in the admin.” This is what the examples are showing, and this is actually a pretty important point of the homepage. The fields you access from a page are entirely your own and you configure them how you want. If this is something that causes one confusion, then that would be a good confusion because it's revealing a key "aha" point. If this is something that sends one packing, then they didn't get it and are likely looking for something different than what PW is, which is also fine. But my preference is not to present examples that imply a fixed-field system, because that is the opposite of what PW is. Ah okay, thanks, I'll revisit and test it out again for those elements.

It's been mentioned a couple of times. I think functions API should lead the examples, but I understand the concern. Per the mention in last week's post, I'll be writing up all the details this coming week. Take a look, and if I haven't convinced you guys at that point, I'll be happy to change the examples. The only thing is, we'll probably need to come up with new examples because they get too long without the functions API. And at that point, they no longer serve the intended purpose at least on the marketing aspect. Favicons now added. The same could be said of using an API variable inside of a function or method. These are short examples to get you interested, they lack surrounding context regardless of what style API you are using with PW, and there will be cases where they work and where they don't either way. We're just trying to give people a small sip to see if it tastes good, not show them how to brew the beer. However, with that said, the intention is that they will work out of the box. They do work on the dev branch right now (which is the branch we recommend for new installs). This will also merge to master again soon. The examples have always worked on the core Regular site profile as well. Error messages have also been added to detect when you use a functions API call without them enabled, and it then tells you exactly what you need to do to enable it. As far as the core goes, the values set in /wire/config.php have to be settings that work on all existing installations. Whereas the values set in /site/config.php are those intended for new installations. We can't enable the functions API on existing installations—only new installations. The reason is that someone may have defined their own pages() function (for example) years before we even had a functions API, and upgrading to a version of PW that has it pre-enabled would then break their installation. I make an effort to ensure anything that gets added in PW is done so in a backwards compatible manner, and this is why there are properties like $config->installed and independent config files. The mix of approaches is actually relevant here because anything using a function refers to something where only one instance can exist, and anything using a variable refers to something that can have any number of instances. So I would use a variable like $page in an example when the intention is to say "can be any page", whereas I would use page() when the intention is to say "page being viewed", as there can only be one. That is one benefit, but definitely not the only one. Read what I have to say later this week. Context is important here and the statement above skips that. I'm recommending the functions API for front-end templates, where PW manages the instance for you. But this is also where our audience is going to be 99% of the time. Of course if you are developing modules, then neither pages() or $pages is right for you, as you are going to need to ask for them from $this. I'm not trying to appeal to module developers, they already have a good handle on this stuff. I went back and forth on this one a couple weeks ago, but settled on the centered version after a lot of testing. Centered felt much more balanced, perhaps because the lines are so short that all the weight ends up on the left side. These are just short snippets of text, but if it were any longer then no doubt we'd want to go left aligned. Good one and I agree. I think Robin S. also mentioned this if I recall, and I do have it on my list to add this capability. Uikit 3 doesn't come with an autocomplete component (Uikit 2 did), and we don't have one to use from jQuery UI like we do in the admin (since not using jQuery UI on this site). So the current autocomplete search is completely homegrown. I don't really know how to add the arrow key nav to this at the moment but do plan to hopefully figure it out soon. Between the existing wire highlight pointer, and the existing darkened text, and then add on that the text usually matches that of the headline, to me this just seems like way too much emphasis and redundancy if we also add a color change to it as well? At least my opinion is I don't want my eyes to be drawn to that unless I'm specifically looking for it.

Check your /site/config.php file. There is a $config->userAuthSalt salt value present there and it would need to be identical between the two installations, otherwise the two installations are hashing passwords differently. That's usually a good thing, but in your case where you want the existing logins to work, you would want to keep that userAuthSalt value.

@Robin S The download versions should be showing now.

Yep, I've got profilerpro monitoring them and if any url gets more than a couple hits then I add a redirect. It looks like there were a few I missed but slowly accounting for them as they pop up.

In this week’s post, we’ll take a look a look at the new website and focus on some parts of it and how they were built. Then we’ll dive into the latest version of ProcessWire on the dev branch, version 3.0.124— https://processwire.com/blog/posts/pw-3.0.124-and-new-site/

The old logo is back due to popular demand. I've never liked the way it looks next to the newer mark, but reducing the brightness of the word "Process" seems to help a bit, so I think it works for now. The issue with the overlapping dropdown should be fixed now, please let me know if anyone else is still seeing it. You might have to double-test in Incognito mode if you do, just in case something is stuck in the cache. I agree with Adrian's points on Tracy, and also I wouldn't know how to maintain it if he ever decided to go meditate in a cave in India for a year. But I also agree about how useful and important Tracy is and that we should give her first class treatment around here and make it as easy as possible for people to make it a part of their installation. Perhaps the core modules install screen has an "Install Tracy" button, or special site profile, or maybe PW's default error messages could suggest Tracy as an option for additional developer help, etc. I think the example is fine because it just depends if output formatting is on or off. And if it's on, it'll give you an error about what you need to do. The purpose of those examples on the homepage is not to provide a full start-to-finish API workflow, but it's to show some interesting snippets to what's possible in 1 line of code. This is more about marketing than it is about serving as documentation, though of course they are good examples too. Regarding use of $pages vs pages(), I had thought we had it enabled in all the site profiles by now, but it turns out it was in the newest one but not the older ones. I'm updating the older ones so that it is enabled by default. I'm also updating the error handler so that if it detects you are trying to use the functions API but the $config->useFunctionsAPI is false, it replaces the "undefined function" error message with a "you need to enable the functions API and here's how..." message. Tracy actually got me thinking of this because I mistyped something and its error said something along the lines of "did you mean [alternative-function]" (not sure of exact wording) and I found that incredibly helpful. It's showing up for me. It's just there's a lot of stuff with the word "find" in it, so you just have to click on the view-all link. This is actually how we make it possible for that footer to be always up-to-date with the forums, Twitter, etc., even if the rest of the page is on a 1-day (or 1-week) cache via ProCache. It uses Uikit's scrollspy to automatically load the footer via ajax from a separate page that is on a 60-second cache, but only if you actually scroll to it. In this manner, we're getting full cached delivery, and a fully up-to-date News/footer section when/if you scroll down to it.

@matjazp @tpr Thanks! That did it. I know I can edit SVG files as XML but didn't know anything about what changes would be necessary to accomplish anything like this, so I appreciate it.

@matjazp or anyone else that might know — I don't have a tool that can edit SVG images, my copy of Photoshop doesn't recognize them at least. Does anyone know how we can invert the colors of this particular SVG file so that it is white rather than black? That would prevent the need for the CSS filter. Thanks. https://processwire.com/newsite/site/templates/css/images/processwire.svg

It should still show you as being in the Docs section, but I kept the URL prefix as /api/ because there are so many links to /api/ref/ and I didn't want to 301 them at this time, plus I just like the readability of /api/ref/ since it is the API ref(erence). I didn't keep the /api/ prefix for anything else though. The only way someone would notice it says /api/ rather than /docs/ is if they look in the URL address bar and compare it from another page in the docs section. Yes it is, but currently it's too far out of date so I'm not showing it in the docs navigation at the moment. I'm hoping to get the cheatsheet connected to the API Explorer module so that it can always be up-to-date like the API Reference section.