Leaderboard

Thought I'd mention this here too. Both VersionControl.module and ProcessVersionControl.module have been updated to version 1.1.0: VersionControl 1.1.0 includes new public method getHistory($page) for fetching the full history of a specific page as an array (supports pagination and filters, arguments can be checked from the code). The primary goal here was to separate the core logic of the module from display stuff. ProcessVersionControl 1.1.0 greatly improves the diff output for Page fields. Instead of IDs and string diff it will now use actual labels and custom diff logic. This not only looks better, but also makes more sense than comparing a list of numbers and displaying the smallest possible change set between them The Page field update was thanks to this pull request, though it ended up being a bit more complicated than that: https://github.com/teppokoivula/VersionControl/pull/2.

$matches->setStart($input->pageNum * $limit); $matches->setTotal($matches->count); $matches->setLimit($limit); $matches = $matches->slice(0, $limit);

Okay, Just found the tie.

For a Map Marker field named 'map'... function renderLocationsXML($locations) { $out = '<?xml version="1.0" encoding="utf-8"?>'; $out .= '\n<markers>'; foreach ($locations as $location) { // use any fields of $location $out .= "<marker name='{$location->title}' lat='{$location->map->lat}' lng='{$location->map->lng}' />"; } $out .= '\n</markers>'; return $out; } $locations = $pages->find("template=location"); header("Content-Type: text/xml"); echo renderLocationXML($locations);

Another version today (039) with a redesigned settings page:

Nope and nope, but caching URL Segments is supported by both ProCache and the (built-in) template cache. Any chance you could replace GET params with URL Segments for this use case? If that's not an option, I would suggest going with the answer you're not looking for – MarkupCache or WireCache

Better to store the selected pages in a PageArray: $children = $page->children; $uniques = new \ProcessWire\PageArray(); // assumes PW3 foreach($children as $child) { $uniques->import($child->size); } $uniques->sort("title"); foreach($uniques as $unique) { echo "<button class='filter' data-filter='.size_{$unique->title}'>{$unique->title}</button>"; }

Two possible solutions for your author/member pages: 1. Use separate templates for your author and member pages. For the author Page field (used in the publi template) your "Custom selector to find selectable pages" is: template=author|member To differentiate between author and member in your foreach loop: if($item->template->name == 'member') { // do something only for members } 2. Only use a single template for all authors (including members), but add a checkbox field 'member' to the author template to signal if the author is a member or not. To differentiate between author and member in your foreach loop: if($item->member == 1) { // do something only for members }

Running 3.0.29 and when Ryan fixed the latest commit (fix for Issue #1965), I ran it again (as the example shows) to update to the latest version of 3.0.29

The guy is fast folks.

I decided to reinstall XAMPP all over again, and all the sites started to load faster. However I removed all the databases that I had before (about 100). I can't really tell why, but to me, it seems that MySQL was the culprit. One thing that was happening, which was weird: Every time I refreshed the slow site, Apache would open a new port. It came to a situation that i had dozens of ports opened for Apache, instead of just 80 and 443. This was what made me reinstall XAMPP all over again. However, sometimes, in the production server, the sites becomes really slow which means that I'm not out of the woods, yet. In the tests I made, the slowing down is caused in the server because the page takes about 20 to 30 sec. to be received, but then, all the elements take a couple of ms. So I believe that it is some processing or dbase access that is taking too long. When I call my service provider, they always say everything is ok. However, in the production site I only have one active database. An other thing that might be related: The admin users tell me that sometimes, when they try to crop a large image, the site keeps them waiting for ever without managing to succeed the crop. Might it be related to image processing? Third party modules: - Email Obfuscator - Fieldtype Time - Upgrades Checker I turned on the cache for some of the most demanding pages. Thanks pwired, I was looking for a tool that would give me some insight on MySQL performance, monoyog looks perfect for it.

I split it up into two modules. TemplateFileHelper Inspired by Template Engine Factory and Wire Render Pattern. A simple module which hooks Page::Render and adds a global controller / template around the current loaded page if it isn't an admin page or an ajax call. It also takes care about css / js (files, "inline" and "$config->js()") and adds the method "load" to the TemplateFile class (which loads an template with an additional controller file). IntercoolerJS Depends on TemplateFileHelper (page template is current page only, global layout, it defines how to use / handle PW template files to be compatible to my IntercoolerJS module) and loads jQuery and intercoolerjs. I try to implement async js / css load (current page scripts and styles added inside a DIV and moved by JS code). I try to get it work with FormHelper module, but don't know if it would work with the PW inputfields.

Using $page->render() to render the page with its template file (or another file you specify) has been around much longer than the $page->render('some_field') introduced in PW3 but the documentation has been a bit lacking. The cheatsheet doesn't help much and it's not covered in the new API reference - the best explanation I have found is this post from Ryan. Personally I think it would be clearer if individual fields were rendered exclusively with $page->renderField(). Using the existing $page->render() method when that was previously used for rendering whole pages with different options (e.g. the ability to pass your own array of variables) leads to some confusion.

I think you access the array with $options rather than $page->options.

@hellomoto, I took a quick look at your code and there are some issues there, but first things first: I'd like to suggest not going this route at all. This module is intended for change tracking, not collecting data for all page views. I can see at least three problems you will eventually run into here: the amount of data can turn your site unusable (the module is not optimized for this), this module is most likely too simplified for collecting any actually useful statistics, and finally this will slow your site down and make it difficult to cache, since each page load needs to be processed programmatically and results in a database write operation. You would be much better off with a real analytics software, such as Google Analytics – which is free and provides all the features you will ever need in terms of page views. If you're looking to avoid turning your data to Google, I'd suggest taking a closer look at Piwik, which is a free option. Now on to the code issues if you still really want to make this thing work. First of all, you're forcing $operation to be "view" by this row: if ($operation = "viewed" /*&& $page->template->name == "vessel"*/) { What you probably meant to use there was "==" instead of "=". Another issue is related to the row attaching the "viewed" hook: $this->pages->addHook('viewed', $this, 'logPageEvent'); There's no "viewed" method to hook into, so what you're looking for is either Page::render or ProcessPageView::execute: first one occurs when a page is being rendered (via API or web interface), second one when a page is being requested online. Again, I'd like to stress out that in my opinion this addition is not a good idea. Consider yourself warned

Nice of you to bring this thread up on my birthday Joss

Great updates tpr, and settings layout is much better

I've been developing on Linux for years now. I used to have a script, that when run, would do a $DB dump, store it in a folder, that folder along with all recent changes would get rsynced up to the live website. A few seconds later, I would visit a unique URL on the live website, it would run the latest $DB dump script (it would then delete itself and the dump), so it would remain in sync with my local. Simple. Whole thing took no longer than 10-15 seconds. I stopped using it when I made a copy of a project into another project. Ran the $DB script and overwrote the wrong project, lol. I now do things a little more manual and less automated.

Just for the record, I updated my post above: Template cache supports caching URL Segments too Anyway, another solution to your issue would be using a structure like /recipes/categories/cooking/, etc. Doesn't really matter whether those categories are URL segments or actual pages, though with pages it would probably be easier to allow your content editors to manage them.

if you are worried of the urls because you are migrating the site and want to avoid 404s from old links, you can also use this awesome module:

Been in that position multiple times and I can highly recommend Ryan for any PW related work.