ryan

Thanks for all the quotes Horst, Margie and Jmartsch! I have added these into the site. Thank you for all of your feedback and excellent comments/questions. I'm glad you are interested in this, as I love to type about it. ?These are all very subjective things. I've tried to focus on making myself happy with it first. I don't expect everyone to like the same things, as we are all a product of our conditioning, especially as it relates to likes and dislikes of colors, fonts, etc. Even more-so with a global audience. Since I've done the build out this time around, the result is currently consistent with my own conditioned preferences, trying to put my best effort towards that. That's where I have to start. But it won't stay that way and I fully expect design elements (like those you've outlined) to evolve. But because it's all subjective, unless something immediately makes sense to my own understanding, I've got to focus on broad consensus more than individual opinions. That's in part why I want to go ahead and get it online, because it's going to be a lot easier to communicate and collaborate. You are picking things out of the few screenshots I've posted (which is all that can be done right now), but these are just basically thumbnails that lack context. So it's feedback about screenshots rather than an actual site, and I'd like to get to the actual site. The site and the screenshots really aren't the same thing, and the screenshots have a whole different feel than the actual site (for better or worse). For instance, once online, if you think you've found a more suitable typeface, you'll be able to use your browser tools to inspect and change it, take a screenshot and post it, and if it seems pretty unanimous then we'll change it. Other things might take more than just browser tools so I'm also hoping to get it into a site profile. There are other reasons I want to go ahead and get it online. First off, I love the current site, but I also think that for people new to ProcessWire, the current site is starting to look old. I'd become so used to it that I didn't notice until recently. For someone clicking around visiting the sites of the various different CMSs, they likely comparing it to the other CMS sites, all of which look quite a bit newer than ours (I've been visiting them all). We have a great site, but it's a 5-year old site, and I think new visitors see that. I'm guilty of this— I evaluate some product/project/tool or another and don't give a second look to the those that don't subjectively appeal to me with their site. I don't have to love the design aspects of it, but I do have to be convinced that there is quality and that someone cares today, not just yesterday. It has to look relatively new or I just assume the project isn't active, or isn't going to be worthwhile, despite any other factors. Regardless of actual design, that first filter is: "does this look up to date and like someone cares?", because if it doesn't then I'm probably not going to look closer at the product/project. This is of course not very smart, but I've just noticed that's the way my mind seems to work. I'm thinking it might also be the way a lot of us work. So when it comes to the ProcessWire site, my feeling is, the sooner we can get something online that is newer than what's there now (and still accomplishes everything content-wise), the better. I appreciate your perspective and these are good points. Though this is one area where I feel differently. I like what this particular typeface communicates and the way that it does it, though maybe there are others that can do the same. But let me explain. It's precisely those details that draw me to it, because it's just ever so slightly organic. While not apparent at regular body copy sizes, it is in headlines in a few of the letters. It steps outside the expected boundaries every once in awhile, which to me feels like breath of fresh air. Like I hope people perceive PW relative to the others. That little detail of slightly curved strokes on a few of the uppercase letters, when noticed, feels a little like warmth, like the friendliness of ProcessWire, and by that I mean that ProcessWire is more than software, it's community. Anyone can say they are friendly, but ProcessWire actually is. I think it also says something about ProcessWire's API in that it's quality and clear, but it's not just work, it's also something you will enjoy. It's professional first, but there's that slightly warm and organic craftsmanship aspect that goes beyond the hard edges of the cold machine. Lastly, purely side effect, but I do like that some of the strokes slightly curve in an almost wire-like fashion, giving a feel of flexibility over rigidity, which I think is also ProcessWire. But it's primarily the professional while warm aspect that appeals to me. There are all the things I like at least. Maybe there are other typefaces that can do it even better, but I've not found anything that does it quite as well so far. It'd be simpler to accomplish this all with a serif face, but I want the modernity of sans serif without the machine-like coldness, and feel like I found it. I look forward to seeing some other options too, I'm sure they are out there even if I haven't found them. I looked at Molde, and it's attractive but cold, kind of geometric and anonymous, and it's hard not to think of Helvetica, despite there likely being lots of subtle differences. It seems like its strength is in its variations. The condensed version feels like it's starting to relate to PW, except that... it's condensed. ? You might be right, but I think this is one where you'll have to see it in context first, rather than screenshots. I'm well aware that dark text on light background is considered the standard for legibility. So anything that involves paragraphs of text is always on a white background in this site. For pages where the primary emphasis is headlines, links, tiny snippets or copy or images, I'm going with the blue background (which is the same blue that is currently in use on this site). You mentioned intensity but I see calm (maybe it's screen related). Though the intention wasn't really either. It was instead just to have more depth where the content would allow, to show that ProcessWire is not a theme engine and there's a lot of inherent flexibility in how you output content. I wanted to get well beyond the 1-template appearance by having a strong contrast in presentation. To my eyes, it's just as legible as the pages with white backgrounds (and actually, I prefer it for reading, but my eyes have bad floaters so light backgrounds are difficult). But it might be one of those colors that looks great on one screen and not another, so we'll have to see if there's consensus and perhaps fine tune it further. This is an easy answer. The primary audience for the website is web developers (or web designer/developers). The secondary audience is the actual clients that hire web developers, whether that be owners, marketing people, designers, etc. So from a marketing aspect, the purpose of the site is first to get the web developers on board, and second to tell the clients that: not only are they going to love the system, but that it's an exceptionally secure, reliable, safe and really easy-to-use system that will put them a step ahead of their peers. I feel like our old/current homepage only speaks a little bit to these groups and that it's too general and abstract in wording. The new homepage is quite a bit more specific about these two groups. I just need to figure out that darn iMac screenshot, as ProcessWire isn't some tangible thing/object that you show. But I just need a screenshot to show that is compelling enough to capture your eye and make you want to start reading what's on the rest of the page. I have not yet figured out how to show this in a screenshot. ProcessWire is definitely an enterprise tool, but I'm not really interested in spending energy targeting this "enterprise" segment. Several CMS seem to target this, lose the interest of everyone else, and meanwhile the enterprise segment goes off and mostly uses WordPress. ? To a large extent, the enterprise segment listens to their web agencies or in house web designers and developers. I feel that if you are attracting the web design/development community, then you are also attracting the enterprise segment better than you can do directly. The types of users currently working with PW are almost exclusively web developers, and related web design/development agencies. This much is pretty clear. I completely agree that PW is not reaching this audience as well as it could. This really is a primary motivation for rebuilding the site. Also completely agree. And they have come to the right place, but few realize it. That's the challenge to solve. I feel like the new homepage gets quite a bit closer to communicating this, but also think really nailing it perfectly is going to take getting a professional designer involved before it's a home run. However, I think next week when it launches, it'll be a step closer to where it needs to be. Some good momentum to get things going to the next steps hopefully. I largely agree with everything here. I've spent a lot of time writing copy this last week and this sounds consistent with what I've been after. Though I don't think marketing can really be unopinionated per se, because the purpose is to get you to buy into something. For instance, I might say that ProcessWire has the best API, and I really believe it, but such a statement can only ever be an opinion.

I hope that you all had a great Christmas holiday (or other holiday that was last week). And likewise hope that you have a Happy New Year this upcoming week. This week we'll take a quick look at last week's new master version launch and then discuss the status of the new ProcesssWire.com website currently in development: https://processwire.com/blog/posts/rebuilding-the-pw-site-5/

Happy Holidays! This latest master version of ProcessWire contains hundreds of new additions, fixes, optimizations and more. This post covers all the highlights— https://processwire.com/blog/posts/pw-3.0.123-master/

Last week's version 3.0.121 was the first release candidate for our next master version. Several issue reports were covered this week for minor things, and they are all included in this week's dev branch version 3.0.122. Please consider this version the RC2 (release candidate 2) for our next master. There's nothing major to report, but if you'd like to see the list of changes relative to last week's version, please see the dev branch commit log at: https://github.com/processwire/processwire/commits/dev If you have a chance, please upgrade to version 3.0.122 and let us know if you run into any issues. Thus far things are going smoothly and it seems like we are very close to the next master version, perhaps as soon as next week. Since I don't have much more to report than the above, we'll skip doing a blog post this week. But after last week's post, a couple of people asked me about ProMailer (as mentioned, which we use for the weekly email distribution), so I'll be sure to write more on that soon. Attached is a screenshot from the message editor screen that reveals several aspects of the message sending part at least. Thanks for reading and I hope that you all have a great weekend!

@Robin S I don't think there is any particular way to know sort of manual analysis (looking to see what you are currently using). I suppose a crawler or creative find() could be coded up to find all the image sizes currently used on a site, but that's maybe more time and trouble than potential benefit. Though you did just give me the idea that perhaps I could have this module perform a find() on fields like "body" to see if any <img> references to each variation exists, before it matches it. That would be relatively simple. But I think where this tool comes in the most handy is when you are making a change to the dimensions in some Pageimage::size() calls, and you want to clear out the old variations that you know are no longer needed. For instance, I knew very clearly what image sizes I could clear out of the sites directory because I was aware of the dimension change I was making in the code. Of course, if it turns out that some automatically generated image variations were still being used, then PW would just re-create them. Where you'd have to be more careful is with manually-generated variations like custom crops or sizes in a CKEditor field. You can exclude these automatically by using the exclude suffix option, though I'd always recommend using the "dry run" option to see what it's going to delete, before you let it actually delete them.

The RC1 version for our next master release is here. This post covers all the details and information about how you can help. We also look at a a new PageAction module added to ListerPro, and a couple of other new modules currently in development: https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/

Thanks for the feedback. It's a little tricky to demo the site as screenshots as it really changes it from an interactive interface to a static image. Looking at the screenshots is kind of like looking at pictures of a house as opposed to walking around in it. It changes the scale completely to one that doesn't happen interactively, so definitely gives a different vibe than actually using it in the browser. But I'm also not one to go off and disappear for weeks at a time, so want to share what I've got every week, even if the viewing context isn't quite right. Per the earlier posts about the site, I'm not trying to create anything graphically too divergent from what we've got already, just trying to evolve it to the next step, and hopefully a platform/foundation for some of the things you've mentioned, and potentially other people that know how to get there. So I'm a lot more focused on the development side (backend and front-end) than the design side, though also trying to get just enough design going to accommodate the content and various responsive layouts that it displays in. At the same time, I don't want something that's purely a mock-up or placeholder either, because I think phase 1 is replacing the current site and immediately after phase 2 is revisiting the design to make it more visually distinct (which is where we need the designers in the community), then phase 3 updating the Module and Directory sites to be consistent with all of it. I do like additional graphics like you mentioned with those examples, though I don't think some of those approaches (Ora, Statamic, Laracasts) are practical for us. Someone has to create those illustrations. I'm not an illustrator, and I don't think I can hire one every time I want to write a new blog post, add a new module, or add a new tutorial. So I don't feel like this level of graphics/illustration is practical or realistic for the PW site and we instead have to work with what we've got. The only real dynamic visual elements we have to work with are the screenshots submitted to the sites directory. But what might be practical is to have some visual elements/illustrations in the marketing side of the site, where we won't be constantly needing new graphics every week. But if there are visual elements we can add that really help to communicate the message then that's ideal. This will especially be the case with the homepage, which is something i'm not sure I'll even attempt a layout for, but may need a lot of help when it comes to that.

This week ProcessWire 3.0.120 is on the dev branch. This post takes a look at updates for this version and talks about our work towards the next master version. In addition, we take a look at some more updates and screenshots for the new ProcessWire.com website: https://processwire.com/blog/posts/processwire-3.0.120-and-more-new-site-updates/

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!