Leaderboard

What @clsource said, and in addition: I recommend clicking the "Watch button" of "processwire/processwire-issues" at Github (and optionally on processwire-requests) and keeping the incoming emails organized, at least those you are interested in. It would be great though if @ryan could come up with an automatically generated "changelog", one that can somehow automagically be injected into his blog posts and the new docs he is currently working on. Side note: for module "changelogs" I recommend using https://modules.processwire.com/modules/module-release-notes/ by @netcarver Regarding the ProcessWire core changes, maybe Ryan could make it possible for Netcarver to hook into the PW upgrade process so that Github changes can also be listed by ModuleReleaseNotes.

Thats one aspect I love about how you handle PW and the community! The feeling of beeing left in the dark about the future is common for other nice projects and fules uncertainty about it. The constant high quality updates an Blogposts makes me very comfortable and trustfully in PW! Thanks so much @ryan!!! I totally agree and 100% understand all your explanations above. My hope is that some talented designers and PW enthusiasts can support you on the design an UX side of things like @teppo constantly supports PW with very high quality content trough weekly.pw I myself are not a designer but would love to help in implementing some of the designs and ideas on the frontend side...

Not exactly a changelog, but I have been thinking about adding a "What's New" section at the top of the API Explorer panel in Tracy. It would simply list any new methods or properties in the current version compared to the old version. Firstly, would you guys find this useful? Secondly, the catch with implementation is that Ryan doesn't seem to be using @since tags anymore - not sure if this is a recent oversight, or an intentional omission (https://github.com/processwire/processwire-issues/issues/759). If he gets back to me and starts implementing them again, I think that would be the simplest approach. Otherwise I'll need to cache the API explorer results and compare the current to the cached version (on PW upgrades). This isn't a big deal and I guess has the added advantage of showing all changes since your last upgrade (not the last actual version) so if you skip over a few versions, this will be more complete. So what do you think - would you guys make use of this? Can you see viewing the API Explorer panel after each upgrade to see what's new?

Hi, read that:

Hello, Normally ProcessWire api does not change at all. Personally I think is one of the most stable apis I have met in a software product. So any new version contains either a bug fix or a new feature, but not a change in how things are used. So if you want a detailed changelog mostly it would be bug fixes and new features. In my opinion is not needed since the documentation, blog posts and commits in the dev branch are enough for a detailed overview of whats new and fixed. And the forums are a great way of obtaining info about the hidden gems of the API. though, I do not know if a CHANGELOG.md file really exists. Hope it helps ?

An update to the hook in the first post for PW v3.0.117 or greater. // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function(HookEvent $event) { /* @var WireArray $wire_array */ $wire_array = $event->object; $size = $event->arguments(0); if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $chunks = new WireArray(); for($n = 0; $n < count($wire_array); $n += $size) { $chunks->add($wire_array->slice($n, $size)); } $event->return = $chunks; }); This returns the chunks as a WireArray so you have the option of using WireArray methods. So if needed you could do something like: $items = $pages->find("template=foo"); $chunks = $items->chunk(5); $three_random_chunks = $chunks->find("limit=3, sort=random");

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/

Great work @ryan! Especially love the new search!!! I also like the results view of the search alot, clean and with the smart ability to filter by kind. Thanks for listening to our feedback about the skyscraper ornaments. Also, love the API search! What stands out to me is that the screenshots all together (with the exemption of the sites pages) look very uniform – mostly text, headings, lists. Very clean and organised, I like that, but visually there is not much to distinguish. Now I get that you are focusing on the content and structure of the site - so it might just be to early for feedback on this topic: I think that especially on the marketing focused pages, focusing on presenting ProcessWire for new users, stakeholders and designers & marketing departments, more images and specially crafted pages would make sense. But I would even argue that for more developer oriented pages, some images would be helpful. I'm a visual person and nice images for blogs, even modules would go a long way in making the experience on processwire.com a pleasing and joyful experience. Now I totally understand that you probably need support from a few UX and UI gurus but I guess, there are a lot of us from the community who would be more than happy to stepp in and offer support. A few examples from pages I stumbled across the last couple of days: Well crafted homepage with gimmicks (feature-slider): https://ora.pm/home or https://craftcms.com Nice visual blog posts: https://ora.pm/blog Visually appealing modules directory (with a nice touch for developers, the ability to sell your own modules): https://statamic.com/marketplace/addons Presenting many features visually (nice menu on the left): https://craftcms.com/features/all Blog, module and tutorials directory: The new Laracast website probably has a good middle-ground with nice graphical touches while still not to heavily reliant on custom visuals: https://laracasts.com/series One last thought, maybe "features" would be a better title for the "about" page because it's less about an organisation and more about a product. This is by no means negativ criticism, I really like the current progress of our new beloved CMSs home and would only like to offer some inspiration and my thoughts in hope that it helps boost PW. Ps. Sorry for the double post on the blog – from now on I will only post here… did not think about it when reading the blog.

PHP has a useful array_chunk function: it is used to split an array into a number of smaller arrays ('chunks') of a size you specify, which are returned to you in a new array (i.e. an array of arrays). ProcessWire doesn't provide a method for WireArrays that is the equivalent of array_chunk, but we can add a new method for this in hook. In /site/init.php... // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function($event) { $wire_array = $event->object; $size = $event->arguments[0]; if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $array = array(); $count = count($wire_array); for($n = 0; $n < $count; $n += $size) { $array[] = $wire_array->slice($n, $size); } $event->return = $array; }); Now we can use this new chunk() method on any WireArray to return an array of smaller WireArrays. Remember that many array-like objects in PW are WireArrays, including PageArrays, Pageimages and Pagefiles. An example using a PageArray of 'workshop' pages. We are running a series of workshops and there is only time for four workshops per day, so we want to divide the workshops into groups of no more than four and put each group under a heading... // Get all workshop pages $workshops = $pages->find("template=workshop"); // say this returns 12 pages // Split the workshops into PageArrays of no more than 4 pages each $chunked_workshops = $workshops->chunk(4); // an array of 3 PageArrays of 4 pages each foreach($chunked_workshops as $key => $chunk) { // $key is the zero-based index of the array $num = $key + 1; // Output a heading followed by the workshop links echo "<h3>Day $num</h3>"; echo $chunk->each("<p><a href='{url}'>{title}</a></p>"); // $chunk is a PageArray } Another example, this time using images. Say we want to divide the images into groups of three or less - maybe they are to be arranged into rows or we are giving the groups some special styling. // Say this page's 'images' field holds 8 images // Split the images into Pageimages objects of no more than 3 images each // 8 does not divide evenly by 3 so the last Pagesimages object will contain only 2 images $chunked_images = $page->images->chunk(3); foreach($chunked_images as $chunk) { echo "<div class='image-group'>"; // $chunk is a Pageimages object foreach($chunk as $image) { echo "<img src='{$image->size(300, 300)->url}'>"; } echo "</div>"; }

Something that I found useful recently... Users can type a date/time directly into a Datetime field, which can often be faster than using the separate controls in the datetime picker. But the problem is that there's nothing built into the Datetime inputfield to let users know what the expected input format is for the date/time. You could enter the input format in the description or notes for the field, but you'd have to do this separately for every Datetime field and remember to update it if the input format changes for any reason. Instead, you can use a hook to automatically show the current input format in the notes for all Datetime fields: $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->notes = 'Input format: ' . date($datetime_input_format, $ts); }); Or as the title tooltip if you prefer (you have to add the title to wrapper because a title on the input itself gets wiped out by the JS datepicker): $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->wrapAttr('title', 'Input format: ' . date($datetime_input_format, $ts)); });

Delete cache folder. Error will be gone.

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.

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

Hi there, is there a detailed changelog for new PW versions other than in the blog post announcing the updates? Or do we have to look into the PW repo on Github to see which changes have been made to the new version? Greets, Martin

Nice, thanks. Another option could be to append the format hint to the field label in parentheses to avoid messing with the notes (not to overwrite any existing).

Some people have this strange problem. We did migrate from a Pantheon site (it was on Drupal, remember), and it's as if the SSL certificate is still stuck in Pantheon, which is not. My IT teams is on the case. Not all people has this problem.

Well, while I like your idea, a "changelog" would be more useful. Sure, we are talking about two different things, at least API additions and changes are part of the changelog and not the other way around. Regarding your idea, the solution relying on a cached version sounds very useful, however, the absence of the @since tags is a pity, I agree. Utilizing both would be the best... ?

Perfect ! It works ! Thanks a lot !

@celfred - sorry, looks like I forgot to commit that new 4.15.5 version - please try updating now - this new version should prevent the error.

Please don't misunderstand - the blog posts and newsletters that precede or follow an update are brilliant! The problem is, sometimes even small changes could break things. The trigger for my posting was the last update. It wasn't clear if e.g. the .htaccess changes will be applied. If a changelog had been available - best displayed before the update process - this would not have been a problem. So I had to compare the .htaccess first. But I'll follow the processwire/processwire-issues" at Github to keep track of all changes.

Thanks guys. I'll make a note not to include the cache folder in deployments.

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 stupid bootstrap div class="row" thing is really one of the main reasons why I love uikit's grid system so much. There it is as easy as this: <div class="uk-child-width-1-1 uk-child-width-1-2@s uk-child-width-1-3@m" uk-grid> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> </div> And you instantly get a nice grid that is stacked on mobile (full with), 2-column on small devices upwards and 3-column on medium devices upwards. No html-row elements and lots of further options (divider, modifying grid item order responsively etc). But as you are limited to bootstrap I guess it might be worth taking a look at http://arnaudleray.github.io/pocketgrid/ to make your life easier.

@arjen the support via lazyload sounds very interesting. This way we only have to care that both fileformats are available on the server. There is no extra markup needed. Only downside is the missing noscript support. So the usefulness depends on the usecase. ?

Hi @bernhard, I appreciate and understand all your comments, but I feel like you are missing the point. There are two concepts/workflows at play, and whilst they aren't mutually exclusive they do serve different purposes. Migrations = manually migrate config and content changes by writing php using the API JSON Export/Import = automagically migrate config (not content!!!) changes you have made in the admin panel Both have pros and cons and in some situations one or the other may not even be viable, therefore the choice is important. I personally wish you could export field definitions as php (like you can with ACF), which is sort of a middle-ground between both these options. To be clear, my feature request was just about updating current core Import/Export to (optionally) enable a more seamless workflow like the below screencast. In it I migrate a new field defined in the admin from one wordpress installation to another in seconds. You cannot do this with Migrations, and with version control and the right logic for syncing this is a completely viable way to migrate config. I am not suggesting this should be the canonical way to migrate config, just one option that sits alongside something like Migrations.

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 ?

Thanks Ryan for the latest update and listening to the voice(s) the community! Congrats to your new iMac! As @HMCB mentioned, it's always nice to work with a tool that you can admire, makes working so much more fun. @ryan Speaking of nice tools, want to share something I came to love very much, would hate to switch back to the old way of having installed my dev-stack locally: I switched to AWS Cloud9 (fully cloud based development stack: IDE, Server, PHP, DB… Amazon…) for basically all of my development and love it, it makes you basically machine (and OS) agnostic. I can continue anywhere in the world with my development with only a decent browser and internet connection. If you've got the time, check it out. For me and working in a team or with collaborators (community) its so convenient! Some of the amazing thins you can do: - Rapid prototyping: Instantly clone a project with all settings etc, try something, throw it away - Share the whole stack with someone, no need for the other person to install anything, simply share a url, everything is there, Server, Shell, IDE, DB… - Collaborate in realtime on a project (google-doc style) - Create a template container and quick-start your project … And since PW basically does not story any urls in the DB, I'm so quick in duplicating Projects with new URLs etc. Ps. If you're new to the Mac, usually what people do is; they know a tool from the windows world and if there is a Mac version of said tool, they install this one – but many times there is a better native Mac App that does not even exist for windows and you'd therefore don't know it. Look out for these. As a simple example: Looking for an FTP Client you could easily end up with some crappy windows/java port – or you'd end up with Transmit… It's worth looking for these quality alternatives. Also, for example for PDF (Adobe Acrobat) handling, or image annotation, or screenshots or screen-capture or… etc > the Mac can already handle it for 95% of the required work with native Tools like the Preview-App or system-wide features…

Hey guys, now the language pack is also linked in the modules directory at https://modules.processwire.com/modules/german/

I've modified that first post with a new update to link here. Let me know if you'd like anything changed.

I'd like to have more people see this as well. I'll let another moderator pin this if they see fit, but in the meantime we have 30 new stars since this post - much appreciated to everyone who took the time, but I am sure we can do much better! I promise I won't gratuitously bump this again

@horst There's a pull request on your module that should update the formatting of the Changelog to allow it to be parsed by the existing code in my module. I've also fixed a couple of issues with the Markdown in the readme file as well. I hope this helps. As long as the changelog markdown is of the following format, markers should be correctly inserted... # Changelog // this line is optional - not needed, but if it is present it is sliced off and presented left justified above the versions. ## {version string} {optional information, usually the release date} // H2 - github will style this with a bottom border - Change 1 - Change 2 - or - ### {version string} {optional information, usually the release date} // H3 - github will style this without a bottom border - Change 1 - Change 2 @tpr There was a bug in the way I was comparing versions. You should be able to stick with whatever formatting you prefer. That said, I think there is more flexibility with string versioning than using integers. With string versioning you should be able to have deep version if you'd like - "0.7.8.1" or "1.5.2dev" are all possible. I'll be moving my modules over to string versions as and when I update them from now on.

THANK you @BitPoet for the answer and @Neo for posting this Q — totally saved me from a frustrating end to a day of coding. I suppose standard practice for uploading a site is to not transfer the contents of the /assets/cache/ folder? If so, I'll bet this is documented and I missed it…

Although your approach would be a bit faster (less function calls overall), it can be turned into a hook and be called on any class that extends WireArray, basically any collection returned by ProcessWire API // /site/ready.php wire()->addHookMethod('WireArray::chunk', function (HookEvent $e) { $chunkSize = (int)$e->arguments(0) ?? 1; $e->return = array_chunk($e->object->getArray(), $chunkSize); }); A common use case is to build grids <?php $myPages = $pages('template=my-template'); ?> <div class="grid"> <?php foreach ($myPages->chunk(5) as $chunk): ?> <div class="row"> <?php foreach ($chunk as $item): ?> <div class="col"><?= $item->title ?></div> <?php endforeach; ?> </div> <?php endforeach; ?> </div>

I do not think too many functions/methods should be implemented in the core, especially this unique one, although I get the usefulness of it as a shortcut. BTW, here's the docs of $wire->addHookMethod with another example https://processwire.com/api/ref/wire/add-hook-method/ And for those who want to get more OOP: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/