Leaderboard

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/

@Leftfield Welcome to the community. The easiest and most performant way is just to make page tree reflects your desirable URL structure. But often such structure looks messy. You can change it by using URL segments and rewriting page paths for your category and post templates. For example, for blogs, I use such a structure home/blog/ /authors /categories /cat1 /cat2 /posts /post1 /post2 I got such URLs site.com/blog/category/cat1 site.com/blog/posts/post1 etc. But I want to have such URLs and I want that every post can be listed in several categories, but for preventing contend duplication I want that it has only one accessible URL site.com/cat1/ site.com/cat1/post1/ site.com/cat2/post2/ To make it work you have to: 1. Enable URLs segments for your home page. 2. Create to Page Reference fields and add it to your post template blog_section - Page reference field ( Page field value type set to Single page, selector 'template=blog_category') - this one we will use for building URL for the current post. blog_categories - Page reference field ( Page field value type set to Multiple pages, selector 'template=blog_category') 2. In your ready.php $pages->addHookAfter('Page(template=blog-category)::path', function ($e) { $page = $e->object; $e->replace = true; $e->return = "/" . $page->name . "/"; }); $pages->addHookAfter('Page(template=post)::path', function ($e) { $page = $e->object; if ($page->blog_section) { $slug = $page->blog_section->name; } else { $slug = $page->parent('template=blog')->name; //fallback } $e->replace = true; $e->return = "/" . $slug . "/" . $page->name . "/"; }); 3. In your home.php if ($input->urlSegment3) throw new Wire404Exception(); if ($input->urlSegment2) { $post_name = $input->urlSegment2; $match = $pages->get($sanitizer->selectorValue($post_name)); if (!$match->id) throw new Wire404Exception(); echo $match->render(); return $this->halt(); } if ($input->urlSegment1) { $category_name = $input->urlSegment1; $match = $pages->get($sanitizer->selectorValue($category_name)); if (!$match->id) throw new Wire404Exception(); echo $match->render(); return $this->halt(); } It's not tested and there can be some errors, but I hope you get a general idea.

I forgott about it, because @tpr made it an official and configurable module and took over the maintainance, whereas I served the startingpoint:

I'm not sure if it's still applicable, but there's an old module as well: https://modules.processwire.com/modules/pageimage-remove-variations/. Although I'm guessing that @horst already knew about it... ?

The PageActionClearImageVariations module sounds very useful, thanks @ryan. I have a number of sites where I suspect I have a significant amount of wasted disk space due to orphaned image variations. Trouble is that I don't think I would able to identify the orphaned variations from attributes such as width and height. What would be ideal would be if there was some way to identify orphaned variations based on whether they are called within any site code (template files or modules). Do you think there would be any way to accomplish that? Another idea I had was to see if fileatime() could be used to check if a file has not been accessed in a long time (which would be configurable) but based on a quick test it seems that the last accessed time does not get updated when an image is loaded by a browser. Any other approaches that could be useful here?

I think if they exist as image variations they have to be rebuilt.

Hi Michael Wether it’s a blog, or a news page or a product overview page, the fundamentals are the same. 1. This makes most sense and is a well organized structure. I like to create a page called blog. This is the blog homepage or overview listing a small preview of each blog post. In a sub folder under blog I actually store my blog posts in a sub folder called called posts. This is because within my blog folder I also have pages for tags and categories and archives I want to keep them all orderly. You’re probably not at a point where you want tags and categories but it means in future you have the foundations in place. But even if you started out differently and realized you need to re organize everything further down the road, it’s a trivial thing to make your blog work with a different structure and some small changes to your selector in your template 2 you can display a smaller image with css or look at the image api and specify a width or height etc 3 on your blog article template, create a field for each and then pull this info onto any page you wish wether it’s the blog home or the homepage etc 4 you would have 1 blog post template and every page would be based on this template Sorry this is so general with no actual examples but I’m typing on the phone.

Without the new module, you would have to temporary modify your template files by adding the following param to the options array "forceNew" => true for every pageimage call that you wants to be affected.

@Ivan Gretsky thank you for helping!!! I really appreciate!!! Here's how I solved thanks to my friend @OLSA: $exclude = new PageArray(); $exclude->add($fav); $exclude->add($favs); $cards = $pages->find("template=blog-post, id!=$exclude, blog_post_sticky!=1, sort=-blog_date, limit={$blogSettings->blog_quantity}");

Old discussion, but yeah – the plus sides of this kind of naming are that 1) it's a common practice across different systems (which makes it easy for new devs to grasp), and 2) that it's a very commonly typed function – not to mention one that you often see in front-end (or "view") part of a site or an app, and thus it's good to keep it nice and short . Expanding on the second point a bit, in the view side it often makes sense to have short function names, even if they're not particularly descriptive. Think of PHP's short echo tags (<?= ... ?>) or various tags implemented by templating languages: the point is to create minimal clutter, thus keeping view files clean and easy to follow ? --- Note: this thread is not related to module development per se, so I'm moving it to the Getting Started area of the forum.

Solution available in today’s blog post. https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/

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.

It is quite common to use one or two characters for "translate functions", since they are typed and used a lot. Some examples: https://codex.wordpress.org/I18n_for_WordPress_Developers https://api.drupal.org/api/drupal/includes!bootstrap.inc/function/t/7.x https://docs.joomla.org/Making_templates_translatable Underscore appears to be a popular one.

[joke]You're gonna hate underscore.js then[/joke] ?

Thanks ? Yes we built multiple sites for them, all based on the same design with theme/color variations for individual sites. E.g. Osho UTA, UTA Akademie and Osho's Place. Those are built with Drupal though. Hi Bernhard, I agree that a module would be the more ProcessWire-friendly way, I mostly wrote it this way to save time. Since it is client work, we have to budget our development time; given that I haven't really started digging into module development yet, I didn't want the additional overhead. Since the site only has one template, I didn't need to duplicate any code, so I didn't think the benefits of building a module were worth the additional development time in this case. I thought about extending the Page class, but I went with composition over inheritance in this case to avoid unforseen side effects. Though it probably would've been cleaner to use inheritance. I'm not sure this class is general enough to be used in different sites at the moment, but if I have some free time at work or need it for another client site, I'll try to turn this into a configurable module!

Thanks for sharing! Awesome site ? I wonder why you didn't create a module for that. There was a discussion about that recently: But in your case I think it would make sense to pack it into a module. You could then: update it with one click across several websites extend the $page object via hooks instead of creating a new class share it with the community via github&co and the modules directory This: <?php namespace Processwire; use schwarzdesign\PasswordProtectedPage; $protectedPage = new PasswordProtectedPage($page); $protectedPage->handleRequest(); if (!$protectedPage->userCanAccess()) { [...] Would then become that: <?php namespace Processwire; $page->handleRequest(); if(!$page->userCanAccess()) { [...] And it would be really easy to achieve in your (autoload) module: $this->wire->addHook("Page::handleRequest", function($event) { // your code here }); I think you could even get rid of the "handleRequest" call and do that automatically in the background.

Update. It seems to go back to expected behavior if in the template code, you place the pw-append before the id but not after. The order matters. ie. This works: <div pw-append='main' id='main-content'> This does not: <div id='main-content' pw-append='main'>

The current project I'm working on is quite large. I've found that my templates folder is getting a little difficult to keep tidy (even with a decent naming convention). It would be nice to create sub-directories within the templates directory that also get searched when adding new templates. Maybe a leading underscore to signify additional directories that contain templates? Templates _template-group-1 _template-group-2 _template-group-3 Directories without an underscore (ex: includes,tools,etc..) would continue to work as they do now. There may be pitfalls to this approach, but I wanted to throw it out there. Additionally, if any has another method for maintaining sanity in their templates directory, I'd love to hear about it.