Leaderboard

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)); });

@teppo@horst thx for your quick, very usefull, respons The combination of $input->get and allow url-segments in the home page did the trick. I was to much focused on the _main.php, but the real page was home.php. With the url-segments allowed in the home template, the magic of processwire was there. if(($input->get->u) !== ''){ $gebruikersnaam = $input->get->text('u');

https://www.spiria.com After several sites made with ProcessWire, Spiria decided it was time to get rid of its cumbersome Drupal site. To be honest, ProcessWire is still difficult to sell to customers, because this CMS/CMF is not as well known as the most popular ones. The migration to ProcessWire therefore served several purposes: Eliminate the frustrations experienced with Drupal (especially with image management and some structural problems). Allow integrators to learn the CMS during quiet periods, when they are not needed on other projects. Promote the CMS by adopting it. The challenges were many, but by no means insolvent, thanks to the great versatility of this programming framework. Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his ways of doing things. The blog The site includes a very active blog where visuals abound. It was essential to cache the various dynamic components. For example, in all sections of the blog, there is a list of recent articles, a list of "short technical news", another list from the same author, a classification by category. In short, these lists evolve independently. ProcessWire's cache system, including its ability to classify by namespace, has significantly improved loading speed. Cache file management has been placed in a "saved" hook in the useful "ready.php" file. Data migration Importing the blog data was complex because at the time the site was designed in Drupal, programmers had not been used the easily translatable "entities", so each article resided in two different "nodes" (pages). We would have liked to use the core ProcessWire import module, but it does not yet take into account multilingual fields. However, we have used this code as a basis for building our own import module. This is one of ProcessWire's great qualities, as a CMF, it is easy to use existing code to design your own solutions. Reproduce the layout The current layout of the site has been reproduced exactly as it serves the company's needs very well. ProcessWire has simplified the work in many ways. Apart from the blog, which is very structured, the other sections of the site are more free, especially the case study section ("Our Work"). The use of page reference fields has particularly helped developers. As everything is a page in ProcessWire, you can create a pseudo relational database within the site itself. The administrator user becomes more aware of the data hierarchy and has better control over the data. Programming architecture The separation between controllers and Twig visualization files facilitates the management of the multiple components of the site. We haven't really explored the "regions" of ProcessWire, because we prefer not to mix these aspects of programming. This greatly facilitates the timely arrival of programmers in our department, used to an MVC structure, because they have a better understanding of what does what. The Search Once again, we were able to simplify what had been done in Drupal. There are two types of searches on the site, the blog search and the more general search on page 404 ( https://www.spiria.com/potato). The Drupal site search was driven by an Apache Solr server in Drupal. We decided to rely on the ease of ProcessWire and the Typeahead library (for the blog), because we didn't need the power of Solr (or Elasticsearch) anyway. Work to improve performance still needs to be done in this area. We would have liked to have seen the excellent search tool offered on the administrative side available on the frontend. We have not yet had time to explore the possibility of harnessing this code from the core of ProcessWire. Our wish here is that the CMS designer, Ryan Cramer, sees this as an opportunity to offer an exciting new feature to his CMS! Powerful modules We have the excellent modules ProCache (static caching), ProFields (fields that greatly improve the functionality of existing fields) and ListerPro (data search and processing tool). As the site is installed on a nginx server, we have ruled out ProCache for the moment and we are satisfied with the use of the cache() function alone. The ProFields fields are a blessing just like ListerPro. This last module is very useful to correct, for example, import errors (we had more than 800 blog articles, some of which date back to 2013). We used a functional field to gather translations of terms that would normally have remained hard coded and difficult to access in the translation interface (an aspect to be improved in ProcessWire, in our opinion). By grouping translations in a single page, site administrators can easily change or correct terms. Language management What remains a very small irritant for us is the management of languages, which is fantastic in many ways. The fact that there is a default language is both a blessing and a problem. For example, in 2013, blog articles were not systematically translated. We experienced the same situation with a customer's site. If the article is only in English, no problem, we only have to not check French as an active language. However, if the article is only in French, we are still required to create the page in English and make tricks in the code, thanks in particular to a checkbox such as "Not present in English" to reproduce the behaviour naturally present for English (or any language deemed by default). Perhaps there is a more elegant solution here that we have not yet discovered. It's not much, but some clients don't see why there are two ways to do it here. In conclusion In any case, ProcessWire's great qualities continue to appeal to programmers, integrators, graphic designers, users and even our UI/UX expert. The solidity of the CMS/CMF, its functionalities all translated into objects/variables ($pages, $page, $config, $sanitizer, $input... the list is long) allows us to systematize our workflow, easily recover code and reduce production costs. Although it is dangerous to offer only a CMS solution to our customers (hammer syndrome that only sees nails), it is tempting to consider ProcessWire as the Swiss Army knife par excellence of Web programming. As mentioned above, the CMF is suitable for all situations, has very good security tools and its designer has successfully improved PHP methods to make programming very pleasant and intuitive. For us, migrating the company's website to this platform was the best tribute we could pay to its designer, @ryan.

Something else related to sound creation is something a friend showed me recently: https://vcvrack.com/ For anyone into Modular Synthesizer.

You can add get params to every url: example.com/apagename/?param=value To work with it in processwire template files, we have the $input variable instead of the global $_GET variable. There is also $sanitizer. I'm on mobile, so please look out in the docs for the $input variable. (poviding links via mobile is a pain ?)

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

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.

Here something very special, in the days of trillions of colors high dpi screens and VR... art by Mark Ferrari which is absolutely incredible work. http://www.effectgames.com/demos/canvascycle/

This is a simple module to prevent guest users and search engines from accessing to your site. Primarily it is designed for use during site development. Modules directory: http://modules.processwire.com/modules/protected-mode/ Github: https://github.com/adrianbj/ProtectedMode Install and check the "Protected Mode" checkbox Create a user with only the guest role and give the login details to your clients/testers. Of course existing admin users can use their personal logins still. There are some similarities with Pete's excellent Maintenance Mode module, but the reason I built this, rather than using Maintenance Mode is: I didn't want the "Maintenance Mode" badge showing up on the site since this is for development before a site has ever been live and I didn't want the client seeing that badge. I didn't want users redirected to the PW login page because I didn't want visitors to see the PW login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form, and also apply some css to style the login form. Hope you guys find it useful.

@horst problem solved on renaming images by using "Custom Upload Names" module which does really good job with timestamps and also giving automatically better names in general. Now about "Croppable Image 3" module today I noticed a "hidden" error on the cropping page if you have debug mode on and the image is inside repeater: Here is the screenshot with the "hidden" error:

Anybody of you ever came across this error? Seems to be a problem of PHP FPM: https://github.com/php/php-src/pull/3363 What is my alternative? @adrian we use this method in the tracy request logger, so this might need to be changed! Edit: if (!function_exists('getallheaders')) { function getallheaders() { $headers = []; foreach ($_SERVER as $name => $value) { if (substr($name, 0, 5) == 'HTTP_') { $headers[str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', substr($name, 5)))))] = $value; } } return $headers; } } This seems to fix it. If anybody has a better solution please let me know.

Give page table a look. I made a single page site with it. Gideon

@Michkael Doh me! - the class to clear a row in your case needs to be on each 4th item... Recommended change: <?php $i = 1; foreach($page->Services as $Service): $image = $Service->image; $colFirst = ""; if ($i%4 == 0) $colFirst = 'col_first'; $i++; ?> With CSS class: .col_first { clear: both; } Remember to either type the above completely into your IDE or copy/paste into a text-only editor first

@Michkael Sometimes when copy/pasting directly from forum code unexpected and hidden chars end up in the output. I suspect that's what happened here. The (pure) code works but when I copy/pasted to my IDE I found a hidden char after.... "colLast" = "row" in your code. No one's fault and I'm guessing Line 144 was $i++ that failed. Also found that your code <?=colLast"?> had a weird space in it in my IDE. Best practice when copy/pasting from forum code is to paste into a text only editor before copy/pasting into your template to remove any weird, hidden chars. After that and with Bootstrap being your framework, <?=colLast?> in that place will not work for you. Bootstrap needs the row class on its own eg: <div class="row"> <div class="col-md_6"> ... </div> </div> To make it work for you, you could try adding a CSS class: .col_last { clear: both; } to ensure the next item starts on a new line below the previous three

I don't think there is one good practise. There was some discussion about different approaches for page builder like setups lately. Repeater matrix or using regular pages are for sure a good solution.

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).

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... ?

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?

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");

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...

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.

My son is interested in programming not in hardware so our C64 is waiting for its new owner. Just PM me...

Ah, ok. Seems that I have to clarify a bit: with the age of 10, he started with a desktop pc i5 and 16gb ram. From that on, he is more and more interested in retro machines. I'm not totally sure, but I think currently he owns 4-5 (old) Laptops of different decades, an old IMac, 5 mobiles, 3 tablets and 1 C64. The C64 is the most beloved for him, and he works on different hardware parts. Also he has built different audio adapters for DOS Laptops. Unfortunately the Sound Chip of the C64 seems to be broken. Don't ask me! - he told me something that not all 8 channels are working but only 2, and that it is not possible to detect the concrete issue of it with his limited equipment. So, he is more interested in modifying the hardware then in sitting in front of a screen. From time to time I pray, that the C64 is the stop in his retro interest, not that I someday has to look out for a Z4. ?

Hey @Guy Verville, excellent write-up!! Thank you for that! I've been using ProCache for about 3 years now in Nginx without any issues. So, go ahead! ? PS: I'd like to suggest you post in on Medium, etc. as well to increase reach. If you decide so, I also suggest to add to Ryans role: creator and maintainer of Processwire... instead of just designer, as people may only read "graphic/web designer" when they see that.

What @LostKobrakai said. :-). I don't think this is something Padloper should handle. If prices need to be adjusted, we have Hooks for such things. Alternatively, you could add custom price fields to the product template and use those instead, following some logic. So, this is up to the dev. On a side note, I'm not sure I get the rationale of adjusting a product's price based on a customer's location. Shipping, yes, but not the actual product price. Is it because of exchange rates? Aren't those handled by the merchants? I'll consider these when we get to that stage, thanks. My initial estimates was 6 months from when I got started (please see first post). I can't promise that though; it could even be shorter! Thanks for the interest.

New version of Tracy includes 4.7.0

I'm still fairly new here having switched to using ProcessWire for pretty much every project (hence the frequent questions ? ) from Concrete5. Concrete5 has had Gutenberg-esque block-based front-end editing for nearly 10 years longer than Wordpress. Although a finished site using C5 can look great for a site editor/frontend-only user with various drag-drop layout tools, we were finding c5 development had become very convoluted and was starting to make simple website projects unnecessarily complicated. C5's core weighs in at a hefty filesize too. This is why we started researching for alternatives and landed happily at ProcessWire. I already find WP development unnecessarily convoluted, especially compared to the simplicity of ProcessWire. And with Gutenberg, I can only foresee the same sort of headaches ahead for the WP community that we were finding with C5 - namely conflicts between blocks and the core and frontend UI and your design style and functionality being dictated to by the CMS in order to work in the Gutenberg features. Discovering ProcessWire has been a revelation for us - the clean API and design agnostic approach are making everything from simple website projects to complex web apps a breeze, with the added bonus of super simple frontend editing that not only wows client's used to site builder platforms but requires basically zero onboarding too. I would urge anyone thinking of building out Gutenberg inspired modules for ProcessWire to consider the above comments to ensure that what makes ProcessWire special is retained.

If anybody might wonder. This is how to setup permissions for a sub-page of a processmodule: As easy as adding the permission to the nav item! If you want the permission to be created/deleted on module install/uninstall you also have to add it in the "permissions" array: $info = [ 'title' => 'ProcessProjects', 'summary' => 'ProcessModule to manage all Projects', 'version' => 1, 'author' => 'Bernhard Baumrock, baumrock.com', 'icon' => 'thumbs-up', 'permission' => 'projects', 'permissions' => [ 'projects' => 'Run the Projects Management Module', 'aggregate' => 'Create Aggregated Reports', ], 'page' => [ 'name' => 'projects', 'title' => __('Projekte'), ], 'nav' => [ [ 'url' => '', 'label' => __('Projekte'), ],[ 'url' => 'mails', 'label' => __('E-Mails verwalten'), ],[ 'url' => 'reports', 'label' => __('Berichte verwalten'), ],[ 'url' => 'aggregate', 'label' => __('Aggregierten Bericht erstellen'), 'permission' => 'aggregate', ], ], ]; Make sure to logout/login, otherwise you won't see the changes in the menu! If you call the ProcessModule's page directly you will instantly get the result of the changed permissions: Whereas in the menu it is still there until you logout+login: @szabesz you asked for that in the blog comments...

Just add: protected static $fM; at line #19 You'll also need to change line 94 from: self::$fM['type']($f, $fM['label'], $data[$f], $fM['desc']) to: self::{$fM['type']}($f, $fM['label'], $data[$f], $fM['desc'])