ryan

This week is the Thanksgiving holidays here in the US and it’s one of those weeks where there’s no school for the kids, so it’s a little hard to get work done. I don’t have any major core updates to report this week, so I’m not going to bump the version number up today. However, look for a new dev branch version next week. We will also release a new master version before the end of the year… sometime within the next month. Before releasing the new master version, I’m primarily interested in resolving any issues present in the current dev branch that are not present on the current master branch. Meaning, issues that have arisen due to some recent change only on the dev branch (if there are any). So if you are aware of any issues experienced on the dev version that are not on the master, please let me know. Thanks for your help in testing. Even though it’s been a vacation week, I’ve been waking up early every morning to work on the new PW website. Lots of continuing progress, and I should have another update on that next week along with a new dev branch version of the core. Thanks for all the feedback from last week’s post. Among other things, I caught that folks don’t like the skyscrapers anymore (as a visual element), so I’ve taken them out and agree it’s better without them. I’ll have some updated screenshots next week. Off topic, but was so excited I had to tell someone. I got a computer upgrade this week after 4 or so years of working off the same laptop. A few keys on my laptop keyboard recently stopped working (letters in the word “ProcessWire” — I wore them out), so I’ve been using an external keyboard plugged in. That’s been working alright, but made it hard to see the screen since I can’t sit as close with an external keyboard in front of the laptop. It was getting a little tiresome to work on, the keyboard wasn't repairable without rebuilding the whole laptop (costly), and it was basically time for an upgrade, but computers are expensive and I was resigned to waiting another year. Over these Thanksgiving holidays I found out a family member had bought an iMac a year or so ago and didn’t like it, so they were going back to a PC. I said, “hey why don’t you sell that iMac to me?” We came to an agreement. Now I've got it here and am moving my development environment over to this newer computer, and have been working off it for a couple of days and loving every minute of it. It's going to help out a lot with developing ProcessWire.

This week we take a look at what's new in ProcessWire 3.0.119 and then we finish up by taking a look at a few screenshots from the new ProcessWire development website. If you read my post last week in the forum, you may already be familiar with some of these updates, but we'll cover them in a little more detail here: https://processwire.com/blog/posts/processwire-3.0.119-and-new-site-updates/

Most of what I've been working on this week is related to the new PW website. That's includes primarily continued copy writing and site development (about 50/50), and it's coming along very well, though a lot of work. I'm hoping to have it ready to post publicly for collaboration by the end of the year. I'll have screenshots to share well before that though. The content of the site (particularly documentation section) is so much improved from the current site that I'd like to get it online as soon as possible, even if design details and some features are still being worked on. In addition to continued work in the documentation section, this week I also worked on the sites directory. I'm going to keep working on that today rather than writing a longer blog post, so that's why I'm posting this update here in the forum instead. Next week I'll also have ProcessWire 3.0.119 ready. Though you can grab the current dev branch already to benefit from a couple of features that are already in it. These include two items from the processwire-requests GitHub repository, among some other minor updates. Here's a preview from next week's blog post about a couple of new features in 3.0.119: • Robin S. (@Toutouwai) suggested that collapsed file/image and CKEditor fields automatically open when a file is dragged into them. Toutouwai also wrote the code to make it happen. This addition is super convenient, and it works great. • @BitPoet suggested that our ajax file upload capture and write the uploaded file in ~8 megabyte chunks. This is preferable to loading all the file data into memory and then writing it, enabling it to support larger file uploads that might not have been possible before (depending on server memory). Presumably this also can help to reduce server load. Thanks to BitPoet for writing the code to make it happen. Also on the dev branch this week is a new WireArray::slices() method and support for created/modified page dates in pages export/import functions (I needed this to import the PW sites directory entries). I'll have more details on all of these updates and more, next week.

Yes, we should have one hopefully this month.

There has been no change here, the WireArray::new() method remains as it was before. It was only the non-static implementation that was removed, which was present not for functional reasons, but purely so that it would show up in the auto-generated API docs to represent the static version. That non-static version was causing issues in PHP versions prior to 7.x. The static version does not cause issues because it's implemented via PHP's __callStatic() handler. While there are WireArray() and PageArray() functions that can be used the the same way as WireArray::new() and PageArray::new(), the ::new() versions are preferable because they will work with any WireArray derived type, and as a bonus, they can also accept variable argument lists.

This week, ProcessWire 3.0.118 contains several updates and this post covers them all. The most significant update is a useful new addition for viewing and manipulating page redirects, right from the page editor: https://processwire.com/blog/posts/processwire-3.0.118-core-updates/

Continuing work on the new ProcessWire.com, this week we discuss the documentation section of new site as more progress is made: https://processwire.com/blog/posts/rebuilding-pw-website-part2/

Work continues on the new processwire.com website, while the core received several updates including support for Markup Regions "pw-optional" attributes, upgrades to WireArray that make it a lot more useful, and more. https://processwire.com/blog/posts/processwire-3.0.117-core-updates/

My interest in using Uikit for this particular site is largely for the collaborative aspect. Having a common, already-known, well documented and tested framework for the front-end just seems better for collaboration here. I know a lot of people here are already familiar with it as well. There's also the aspect of being able to develop the site without necessarily knowing the final look of it. Uikit is designed for this kind of prototyping and gives us a result that can be tailored using already known/documented means (collaboration again). That there's a lot of crossover between Uikit's components and what we will need for this site is also helpful, and will no doubt save time. The current site was also a collaborative one, but it didn't use a framework. Instead it used various strategies that may be quite good and efficient, but I've never understood as well as I would have liked. So when it comes to making updates on the code side, I feel like I'm working around things rather than with them. Since I've got to ultimately maintain the site for the long term, I like having the familiarity and consistency of an established and documented framework behind it. In the context of the ProcessWire site, these aspects are more important to me than size of the eventual css files. If I was developing a different site the considerations might be different—I might still use Uikit, or I might go a different route, or go sans framework, all depending on the context and needs of the site. So I'm not suggesting that everyone should be using Uikit, just suggesting it seems like a good fit for this particular project, as it has been for some others.

This post contains an introduction to our plans for rebuilding the ProcessWire.com website. In part one, we take a look at the initial strategy, framework, and concept for the new site, primarily from the development side: https://processwire.com/blog/posts/rebuilding-the-processwire.com-website--part-1-/

This week we look at two new versions on the dev branch and a lot of updates. These include new page traversal methods, page list customization options, improved empty trash process, two factor authentication improvements, improvements to the profile editor, and more– https://processwire.com/blog/posts/processwire-3.0.115-and-3.0.116-core-updates/

Last night my cat bit my hand for no apparent reason while he was sitting in my lap. He's a very friendly cat, but also very old and I think may be getting a little senile. It was a deep bite, though didn't seem like all that big of a deal. But this morning my hand was hurting pretty bad, then it swelled up, and then a swelling red line appeared on my skin that went from my hand to my shoulder. I went to the doctor and he said it was a bad one, and if I hadn't come in today I would have been in the hospital tomorrow. Apparently cats have some mean bacteria in their teeth and these kinds of cat bites can get pretty bad, quickly. They shot me with a bunch of antibiotics and now I've got to go see another doctor and get an x-ray because they think that there's a possibility the cat's tooth broke off and may be stuck inside my hand (I hope not!). If the antibiotics do their thing, all should be fine in a few days. I'd planned on writing a blog post today about ProcessWire 3.0.115, but it looks like that's not going to happen (and one of my hands doesn't work so well), so I'll write about it next week in combination with 3.0.116 updates. But if you want to see what's new in 3.0.115 before that, be sure to check out the dev branch commit log. Thanks for reading and have a great weekend!

ProcessWire 3.0.114 is a relatively minor core version update. Most of the ProcessWire stuff I've been working on this week isn't quite ready to commit/release, so will save for later. This version adds a $database->supportsTransaction() method that returns a true or false as to whether or not the current DB engine supports transactions. Or if you give it (as an argument) the name of a table in the database, it'll return a true/false specific to that table. This version also adds importFiles() and replaceFiles() methods to $page->filesManager, which is what manages all the files for a page. These methods aren't likely to be useful in site development, but are useful for a module I'm working on, and maybe useful to other modules, so I went ahead and added them. Finally, probably the most interesting update in this version is that modules can now specify autoload order. This is something that Adrian requested, as TracyDebugger needs to load before other modules, so this update simplifies that. If you develop a module that has a similar need, be sure to see the notes for the autoload getModuleInfo() property in the Module class. That's all there is this week, so I'm not going to do a blog post this week, but stay tuned for more next week! Have a great weekend.

The focus this week was on covering the queue of issue reports, and a whole lot of progress was made. Plus some other useful additions can be found ProcessWire 3.0.113. This post covers all the details— https://processwire.com/blog/posts/processwire-3.0.113-core-updates/

This post takes a comprehensive look at the new Verified URL Fieldtype added to the ProcessWire ProFields package. We also review updates for the latest version of ProcessWire, 3.0.112 on the dev branch: https://processwire.com/blog/posts/processwire-3.0.112-and-new-verified-url-fieldtype/

If I understand the question correctly, you might be looking for a regex capture collection, but I think support for that is really rare and am pretty sure PHP/PCRE does not have such a thing. So I think you'd have to use a couple of regular expressions here: one to find all the {mailto...} tags, and another to isolate their attributes into independent arrays. That's because presumably the attributes can appear in any order and some may or may not be present. Here's how you might do it: function findSmartyMailtoTags($markup) { $tags = []; if(!preg_match_all('/\{mailto(\s+.*?\baddress=".*?")\}/', $markup, $a)) return array(); foreach($a[0] as $key => $tag) { $attrs = [ 'address' => '', 'text' => '', 'subject' => '' ]; if(!preg_match_all('/\s+(?<name>\w+)="(?<value>[^"]*)"/', $a[1][$key], $b, PREG_SET_ORDER)) continue; foreach($b as $attr) { $attrs[$attr['name']] = $attr['value']; } $tags[] = [ 'tag' => $tag, 'attrs' => $attrs ]; } return $tags; } If you wanted to do it without a regular expression, you could do this: function findSmartyMailtoTags($markup) { $tags = []; foreach(explode('{mailto ', $markup) as $cnt => $line) { if(!$cnt || false === ($pos = strpos($line, '"}'))) continue; $mailto = $line = substr($line, 0, $pos+1); $attrs = [ 'address' => '', 'text' => '', 'subject' => '' ]; while(strlen(trim($line))) { list($name, $line) = explode('="', $line, 2); list($value, $line) = explode('"', $line, 2); $attrs[trim($name)] = trim($value); } if(!empty($attrs['address'])) { $tags[] = [ 'tag' => "{mailto $mailto}", 'attrs' => $attrs ]; } } return $tags; } In either case, either version would return exactly the same thing (print_r result): Array ( [0] => Array ( [tag] => {mailto address="someone@domain.com" encode="javascript" text="link text" subject="The subject line"} [attrs] => Array ( [address] => someone@domain.com [text] => link text [subject] => The subject line [encode] => javascript ) ), [1] => Array ( [tag] => {mailto address="hey@hello.com" text="Hi" subject="Welcome friend"} [attrs] => Array ( [address] => hey@hello.com [text] => Hi [subject] => Welcome friend ) ) )

This week flew by too fast. I did some work on the core, but mostly had to focus on some end-of-the-month client work deadlines, in ProcessWire-powered projects. As a result, I don't have enough core updates to warrant a version bump on the dev branch this week, so putting a quick update here rather than a blog post. ProcessWire 3.0.112 should be ready by this time next week. One of my clients recently requested a URL field that intermittently verifies itself—to make sure that the URL is still returning a 200 success, and not a 404 error, or some other error code. Their site has thousands of external URLs (more than they can check manually), and they want some way to avoid showing links for URLs that are no longer working. I thought a self-healing URL field sounded like a cool idea, so put a little work into that this week, and will likely finish it up next week. The module is called FieldtypeVerifiedURL and it extends the regular FieldtypeURL field, except that in its configuration you can specify how often you want it to verify that the URL is still valid. It also performs the verification whenever the value changes. It uses WireHttp to obtain and store the response code with the field, whether a 2xx (success), 3xx (redirect) or 4xx (error) code. So if you wanted to, you could filter the pages with this URL field by response code (like to find all those returning 404s for instance). It can optionally save the <title> tag found at the URL for you as well. In our case, we will be configuring it to check that URLs are valid once a week, and this is something that it will do in the background automatically. When a URL is found to be returning an error code (like a 404), the output of the field can be optionally configured to return an empty value rather than the URL (when output formatting is on). I'm not anywhere near finished with this one, but if this sounds useful to you, stay tuned for more on this soon. Have a great weekend!

This week we look at ProcessWire’s strategy of continuous improvement and refactoring on top of our solid foundation, and in ProcessWire 3.0.111 that brought refactoring to a few core classes and some other useful additions… https://processwire.com/blog/posts/pw-3.0.111/

This week we take a look at a couple of reasons why you might want to choose InnoDB as your MySQL database engine when installing ProcessWire— https://processwire.com/blog/posts/using-innodb-with-processwire/

This week the focus has been on fixing various issues in the queue at our GitHub processwire-issues repository. So while there aren't any new/exciting features to write a blog post about, there are a lot of commits in ProcessWire 3.0.110 that fix various minor issues. If you are running on the dev branch, the upgrade is definitely worthwhile. You can review this week's commits in our commit log in the date range from August 6 to August 10. Also a big thanks to @netcarver who is now helping to administer the processwire-issues repository.

In the last blog post I told you about how two-factor authentication was coming to the core and what our plans were. This week it’s ready to use in ProcessWire 3.0.109, so we’ll take a closer look at all the details and how to use it: https://processwire.com/blog/posts/processwire-3.0.109-adds-two-factor-authentication/

I usually post to the blog on Fridays, but I've been working on ProcessWire-based client projects this week, so nothing new to post today. I'm back to working on the core next week and continuing the 2FA development, so will have more next week. Thanks and I hope that you have a great weekend.

These look like false positives, especially given the last one (a CSS file served by Apache). What's happening here is that your server is taking a long time to respond to the requests, and the testing tool is making the assumption that because it responded slowly, it must have executed the command it sent (sleep and timeout). Most likely your server took a long time to respond to the request because that testing tool is hitting the server hard, and it's either struggling to keep up, or it's throttling the tool, limiting how many requests it'll respond to at once. It's also possible you've got another server-side security tool that is detecting something trying to mess with it, and interrupting the request. With a tool like ZAP, false positives can happen, so you should use it to find where to look, but use the information it gives you to confirm on your own whether it's an issue or not. And if you ever think you've found some security an issue in any software, contact the author directly, don't post it in a public forum. The only other thing I'd suggest is to look at your site template that serves the first URL it mentions, and check if you are using a GET variable named "query", and if so what you are doing with it. However, I think this is unlikely given that it's reporting the same error on a CSS file, which is served directly by Apache, not ProcessWire.

I'm running on a 2013 macbook pro (15-inch) with 8gb ram and 256gb drive. I find it works well for PhpStorm and other web development tools. I don't have photoshop or docker, so can't say about those. It's the most reliable computer I've ever used, and it runs just as well as the day I bought it (not feeling any need to upgrade anytime soon). I do occasionally wish I had 16gb ram, but I don't think I actually need it. This is essentially what I've got, though mine is a couple years older and has half the ram. If you aren't moving your computer to different locations every day, the 15-inch screen is a lot more real estate than the 13-inch, which is useful when it comes to web dev. The 15-inch screen is a big difference to me, and something I can work off of all day. The 13 inch would probably be more challenging, especially in apps like PhpStorm or Photoshop. However, my eyes aren't great. Other things to mention about the 15-inch: It has a 4-core processor, vs 2-core on the 13-inch. But I'm not sure if it makes any difference for the applications you've mentioned. The 2015 model I think is using the older style keyboard (?) which would be a benefit, because it's a lot more reliable from what I understand. Then again, it is used, so who knows. Markets are different depending on location, but the price of the one you mentioned seems high to me, given that it is used. $1275 EUR is about $1500 USD, which is what I paid for my 15-inch MBP brand new. Though when I bought it, it was "last year's model", so the price had come down. But if you are considering the 15-inch, I would look around to see if there are others you could get for less and perhaps be able to negotiate the price down. Notebook computers are much more likely to break than desktop computers, and much more expensive to fix when they do. So a warranty carries a lot of value, and likewise a lack of a warranty should reduce a lot of value. For this reason, I would usually say to buy notebook computers new or refurb (from Apple) if you can, and get as old of a model as possible, that still carries the full warranty. If you buy used, then factor in the risk of something breaking, and on an Apple notebook that could be a $500 repair or more. In fairness, I've had about 5 Apple notebooks over my life, and only 1 of them has had any issues.

I don't plan on forcing the option, though had thought that when enabled, we'd give them a login warning notification asking them to enable it, every time they login. I haven't come across any services that forces me to 2FA yet, though I know some companies require it internally. But I think it might depend on the 2FA method being used before you could say if it would be a good idea to force it or not. There are times where you might want to disable 2FA temporarily too. So I think it's best to let the user control it, and maybe annoy them a bit with warnings when they aren't using it. But this is one of those things where I think we'll start fairly simple, but then start fine tuning the options according to what we find are the needs of people using it. I think support in the core is consistent with PW's strategy of making security the top priority. I think we are soon reaching the time (or already have in some cases) where 2FA is considered essential in order for an online application to be taken seriously as having an emphasis on security. I consider it essential for any other online account I maintain (as I imagine many do), so it should be in PW too. If we step outside the security aspect, I think it also builds trust and checks boxes for a lot of bigger companies that may be considering PW or comparing to other options. The support and interface for it will be in the core. The implementation of the interface will be in modules. There will very likely be one implementation module included in the core, though I'm not 100% positive on that yet. Either way, I'll be building and maintaining at least one of the modules that supports it. As I understand it, Google Authenticator is just a standard implementation of RFC 6238 and RFC 4226, like any number of other authenticator apps. As far as I know, they are compatible with each other, but Google Authenticator is just the most widely known/used. I think the compliant you mentioned is the nature of the technology, and not really anything about Google Authenticator in particular. But the complaint is also the reason why it's secure. Once one understands how it works and the steps they should take, I think it all make sense. I'll try to describe. The reality is that 2FA is an extra step, which you can't deny is an inconvenience. But it's like locking your door before you leave the house. Nobody likes having to take extra steps, what they like is the security benefit (if they understand it). And if you lose your keys, then yes you are locked out, unless you've got a backup method. This is why services typically provide backup 2FA methods (like SMS) or one-time use backup codes that you can store securely somewhere in case you ever lose your device. For every place where you use 2FA, you've established "a secret" between your device and the service/website (a long base32 string, which can also be represented by a QR code image). The reason it is secure is because it's not shared anywhere else. If that secret were stored up in the cloud or synced between devices and such, then it is becoming less secure. It is getting passed around networks just like your password, which kind of defeats the purpose of 2FA. If you buy a new phone, and can't restore backup data from your old phone for some reason, the yes you'd want to reset your 2FA for the new phone. If you've got your old device handy, then you'd switch the 2FA to your new device. If your old device is lost or non-functional, then this is where a backup method and/or one-time use code would come into play. If those options weren't available, when it comes to PW, one could also fix any of this by asking a superuser to reset it even temporarily disabling from $config (if nobody had admin access). As I understand it, this is simply a matter of a user 2FA off for some account, then turning it back on, so they can establish a new secret/QR code. There's already a password reset module built into PW. 2FA can be disabled for any individual account as needed. This is what the superuser account is for. ? This is definitely part of the plan. Though with the 2FA methods I've been working with, we can't enable it for anyone that hasn't set it up themselves. Maybe with Netcarver's PPP module when using email, it could work. Or maybe it would work with SMS when you've already got the user's mobile phone number stored. It needs to know the user name in order to be able to look up the user-specific secret for the codes. Technically it doesn't need the password. But 2FA without a password is no longer two-factor, and would have its own security problems, which might be even worse than not having 2FA in the first place. If someone gets a hold of your device, and needs no password for your account, then they essentially have access to your account. Whereas, the intention with 2FA is that both your password AND your device are necessary. It's that combination of factors that makes it secure.