Leaderboard

We upgraded a big multi language site to 3.0.200 and to PHP 8* + MySQL 8 a couple of days ago, several thousands pages, lots of templates and fields (120MB DB). The upgrade went fine, and the site is running super fast! I didn't measure with tools, but just by reaching the URLs of some complex pages and you can see it loading waaay faster. The client could not be happier. ? Fantastic job, Ryan and the other contributors! Thank you, Sergio --- * I used RectorPHP to help upgrading my custom modules, which was nice.

hi, even it's a funny idea as - you'll be multiplying duplicate contents between this latest-article and... the latest article - the content of this latest-article will change quite often it's quite easy to achive, just use $pages->find with template and sort by -date (with your own field naming convention) to get the id of your latest article on top of the code and then use $pages->get(xxxx)->content and so on to display the latest article content/images/... in the page hope it helps have a nice day

This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.

@JerryDi I don't think there's a right answer as to what would be the best structure for your case. It really comes down to your needs, which I don't have enough familiarity with this to give an ideal answer. You'll be able to build your search for championships by club, player, etc., either way, as PW will make that simple. You can have any kind of parent/child relationship for those championships such as… /years/year-num/championship-name/ /clubs/club-name/championship-name/ …and so on. But another route to take (and what I might recommend here) would be to have a /championships/ parent and have all the championships under there, perhaps auto-sorted by year. Each with fields for "year", "club", "players", etc. /championships/championship-name/ And perhaps fields like "club" and "players" on each championship page would be page references to other pages setup in a similar structure: /clubs/club-name/ /players/player-name/ …and so on. Taking this route (where all championships share a common parent) may not be perfect for any one need, but will likely be a good fit for a diverse range of needs, a solid choice overall. So without knowing the details of your needs that's the route I'd probably take.

As an option https://processwire.com/blog/posts/pw-3.0.173/#telling-processwire-what-page-to-render

Hey @Richard Jedlička just wanted so say thank you as your module is really helpful in my daily work ? Also thank you for your suggestions regarding RockMigrations field context syntax, I'm using that all over and it makes the migration syntax a lot better!! ?

If using "Select options" fieldtype is not a requirement and you just need to have a more visual way to select things, you could use "Page Reference" fieldtype with InputfieldSelectize.

Hi I created new module for adding links to quickly edit a field directly from page edit. https://processwire.com/modules/admin-helper-links/ You probably already know existing module HelperFieldLinks created by @Soma which was my inspiration. I was using that module for a long time so thank you @Soma! The reasons for this new module are that HelperFieldLinks seems inactive and contains few bugs. I decided to try to fix them, but after a short time I realized a better (i think) and simpler solution and also got some new ideas how to improve. I used javascript instead of PHP and modified a code which is already in PW source code to show field names when you hover the inputfield's expand arrow (in debug mode). I also moved the cog icon next to the expand icons which doen't break the layout so much. What is missing is the field info panel with it's props, never used it, but it can be done too. The template edit links needs to be added too. If you got some ideas how to improve, tell me.

I am new to ProcessWire and liking what I see. Could I ask for a bit of guidance. I am building a web archive for my county golf association. We have 90+ clubs. Clubs have players who win championships and/or play for county teams, and the clubs host these events. We have around 12 championships a year with results going back over 100 years. My objective is to be able to select a club, championship or player and see related events / results for each. My data is in csv files and I need to import this [already done the clubs, the import module works great]. My question is re structure and whether, for example, I need to have championship results as a child of the championship main page or whether it would be simpler to create queries to get the data I need. Any guidance much appreciated. Jerry

@Manaus This is a case where you should do a 302 redirect $session->location($article->url); rather than render different articles at the same URL. Otherwise folks won't be able to accurately bookmark it, and it'll confuse search engines, so it'd be an SEO problem. But I'll assume you know that and you want to do it anyway. What Zeka mentioned above is a good way to go, and probably the one I'd choose. But here's also another option below. It assumes you have a "latest-article" template and it is used by the page /latest-article/. /site/templates/latest-article.php $article = $pages->findOne("parent=/articles, sort=-created"); if(!$article->id) wire404(); echo $article->render(); If you are using prepend/append template files, then you'd also want to check the box to disable them in Setup > Templates > latest-article > Files (tab).

Awesome - thank you! I had forgotten that class_exists tries to load unless you set that optional autoload argument to false. I've made that change so the new version has it. Thanks again.

@bernhard Hi, I'm happy to hear that ☺️. Sorry, I still haven't fixed the labelless fields. I'm in a focus on other projects right now (non pw-related).

It doesn't make sense to put the parent path in a check against the page template, but you can check the parent path separately: if($page->template != 'booking') return; if($page->parent->path !== '/nya-bokningar/') return; // The rest of your hook code...

Thank you! The 'by hand'-way works.

great news thank you

if(class_exists('\Tracy\Debugger', false) && Debugger::isEnabled()) return; Works for me. We just tell PHP to skip autoloading, so it will never know about the composer version.

@Nick Belane Hi, fixed it but haven't found the origin of the issue. I just downloaded the latest PW (3.0.184 by the time) and replaced the wire directory, index.php and htaccess by hand. But as the current master meanwhile is 3.0.200, try to repeat the upgrade steps. Maybe there is no issue with this particular upgrade. Even though, you should be save to replace the mentioned dirs/files by hand (Nonetheless i recommend backing up all relevant folders).

You can do this with a little bit of extra CSS. This example is what i use for a radio select .Inputfield_select_option input + .pw-no-select { position: relative; padding-top: 70px; margin-bottom: 20px; width: 100%; display: inline-block; text-align: center; color: #333; font-size: 14px; cursor: pointer; } .Inputfield_select_option input + .pw-no-select::before { content: ""; position: absolute; width: 100%; height: 50px; top: 0; left: 0; display: inline-block; background-size: contain; background-position: center; background-repeat: no-repeat; border: #d9e1ea 1px solid; border-radius: 3px; margin-bottom: 5px; } .Inputfield_select_option input:checked + .pw-no-select::before { border: #2a2a2b 2px solid; } #Inputfield_select_option_1 + .pw-no-select::before { background-image: url(images/option1.png); } #Inputfield_select_option_2 + .pw-no-select::before { background-image: url(images/option2.png); } #Inputfield_select_option_3 + .pw-no-select::before { background-image: url(images/option3.png); } To add a custom CSS the link below shows one way of doing so.

Wow, This bug has been fixed with PW 3.0.200 !! ? ? @ryanThank you so much.

Happy to report that this issue has now been resolved. Thanks to @csaggo.com for the report and proposing a solution. This has now been implemented across all number HTML inputs. To upgrade, please grab the latest download. ps: the UI has changed slightly from the screenshots I posted in earlier posts in this thread. Thanks.

I've done both so far. Since we use PW for our corporate intranet, there are a number of additional databases we pull data from, which is quite straight forward (just an include that instantiates a new WireDatabasePDO and wire()s it). We have a search interface to our test report database where all the data for on-site test runs of our machines are stored, pull in infos about the processing state of lab samples and display an ajax loading tree of standard parts lists for the project engineers from the ERP. Other DBs have been converted to PW pages, like e.g. the archive for the old support ticket system. We even have a mix at some places. For our sales department, we pull the contact information for our worldwide offices from the ERP, create pages if they don't exist yet, and the department augments these pages with additional infos like contractual details that the ERP can't store without climbing through major hoops. We have a semi-live attendance list (the most visitied page by far) filled with data combined from PW's user list (synchronized from Active Directory), attendance status from the time accounting software and person info like the building/room number from the ERP, with the HTML output being generated every five minutes by a background job to ease server load a bit. We have some additional, non-PW tables in the PW database for speeding up things, like caching the listings of large directories with parts drawings, and even wrote our own CKEditor plugins to easily embed links or image tags for these files. You could say PW runs as a big "spider web" that connects all the apps in our company, with data being pulled in wherever necessary. There are a few apps where we thought about storing the content in PW but decided against it due to the sheer amount of data and the performance impact PW's normalization would bring. Right now we're at around 25k pages and a little over 100 fields in 50 templates. We use the UserGroups module and template settings to limit backend access to individual templates and keep the list of available templates short for our editors (~60 editors who never see more than 6 templates in their selection list). Our intranet was built on a different CMS in 2006 and migrated to PW a few years ago, and the possibilities we gained were simply astonishing. It's always fun to have a sales rep for one of the intranet platform solutions on site and, after listing to their spiel about the great features they offer, show them what we have and ask innocently, "How much work would it be to implement all of this?" ?

I've been doing something very similar -- might I suggest a small change to the page selector to eliminate the need to check for the current page in your foreach loop? // Find the pages that use the specified tag -- and ensure the current page is excluded $articles = $pages->find("template=basic-page, id!={$page->id}, tags.title=$tag, limit=8"); This way, you always get 8 results (if there are that many, of course), whereas excluding page from the loop would leave you with 7 pages.

Just edit the url of the "Admin" page in the pagetree.