teppo

Actually couldn't help mentioning this in the latest Weekly issue. Apparently Italian and Polish versions of Burger King's site are running ProcessWire, others use Drupal. Perhaps, just perhaps, they're converting others too?

Mostly using Pingdom and Nagios. Pingdom is for personal projects and as a backup for cases where Nagios itself might've gone down, while Nagios is for anything where I really need a "full-featured" monitoring service. PHP Server Monitor seems like a nice tool, though judging from their documentation (didn't install, so please let me know if I got this wrong) it seems to lack some features I've grown accustomed to: customisable user groups and per-group behaviour, different actions based on time and day/date, service/server specific actions, SNMP support and/or support for custom check logic, etc. If you just want to know whether each specific server/service is up and have a reason to avoid hosted services like Pingdom, StatusCake and UptimeRobot, this does indeed seem like a good tool. For most use cases I'd still recommend a hosted solution, mainly because a) ease of use and b) they pretty much guarantee that the monitor itself won't suddenly die without a notice

Thanks. Currently working on some pending fixes, but I'll take a closer look at these soon

This should've already been the case, but in certain situations things weren't working as expected. The icons were displayed if there was at least one row of data in the database for that page and field combination, and a bug in building the base dataset often resulted in *all* fields for enabled templates (and not just the enabled ones) having that one row of data. I pushed a fix for the config issue a while ago and I've just pushed another fix that skips non-enabled fields even if there is data for them. Still need to make some updates to the automatic data (re)generation part, but for now things should appear normal

@tpr: thanks. With your test environment this was easy to reproduce and I've just pushed a fix to GitHub To be honest I'm not entirely sure why this was broken in the first place, but it has something to do with the way isset() implementation has changed in PHP 7.0.6. Found a bunch GitHub issues related to other frameworks where this has also caused issues. Ditching isset() works in this case, since nothing that evaluates to false should be a valid value here anyway. @ryan: doing isset($this->input->get->pages_id) in a Process module resulted in "false" in PHP 7, even though $this->input->get->pages_id returns a value ('1234' or something along those lines). Unless I'm mistaken here, this might be something that the core should account for. Seems to be related to https://bugs.php.net/bug.php?id=72117.

Gee, this part sounds familiar

Thanks! I don't have an environment with PHP7 at the moment, so might have to set one up later, but for the time being it would be cool if you could check your browsers dev tools (net panel) for me Once you open the admin page, there should be an AJAX request for an URL like this: http://www.example.com/processwire/setup/version-control/page?pages_id=1031&settings%5Bempty%5D=true&settings%5Brender%5D=HTML Are you seeing this there? Is it returning status code "200 OK" or something else?

If you still want to go with the .htaccess route instead of Jumplinks, you might want to provide us some additional information. What I mean is that, for an example, /solutions/eventdirect should definitely redirect the user to http://www.mngdirect.com/eventdirect. Are you saying that this redirect doesn't happen at all? Another thing I find curious is the placement of these redirects in your .htaccess file: here you've got "RewriteEngine On" right after "Options +FollowSymlinks", but in the default .htaccess setup "RewriteEngine On" is placed much later in the file. Did you alter the .htaccess file and add *additional* "RewriteEngine On" row, or how did you end up with this setup? Which version of ProcessWire are you using, by the way?

Thanks for reporting this, @tpr. Any suggestions for reproducing this issue would be welcome, though – when and where did this happen, what were you doing then, does it happen consistently or just sometimes, etc. So far everything seems to be working just fine for me. Installed a fresh multi-language site and using the latest version from GitHub (3.0.29 with some off-version fixes).

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.

Agreed and agreed. To be honest I tend to prefer code over documentation (documentation gets stale, code is always relevant), but it would be nice to have these things properly documented. While it's true that using $page->render() for multiple purposes depending on the formatting of the first param can get pretty confusing (and in my opinion that isn't really good design practice), the thing is that it can still be used just like earlier, you just need to be specific with the params you use. In other words: nothing was removed, new features were just added.

If that's the case, it seems like you could just use $page->render('filename.php', array('closing' => 'whatever')). Please let me know if I'm getting this wrong, though.

Right, corrected. We're dealing with a TemplateFile here, so it's indeed either $options or $this->options

Just for the record, $page->render('some_field') does indeed call renderField(), but only if the given param is a field name. Take a look at PageRender for more details. If you provide a filename as a param, $page->render() will use that file to render given page. If you provide a filename (actual filename, not just something like "file") to $page->render() as the first param, you can provide an array as the second param, and the values stored in that array can then be accessed via $options. It seems to me that you're trying to use $page->render() to something it's really not meant for: $page->render() is intended for rendering a specific page (optionally using a specific file), while wireRenderFile() renders a specific file without the need for a Page object. Those are two different use cases. I might've gotten your intention wrong, but that's the impression I'm getting

@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

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.

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

@arjen If you're still waiting for a reply, I would suggest contacting Marvin via Twitter. Last I checked, they were indeed offering this module commercially.

Just a quick comment on this one: if you enter just one dimension, doesn't that automatically update the other one? At least in my case it does

Since you're using Redirect / RedirectMatch, both of which are features of mod_alias, there's no way that I'm aware of to do this. What you should do is move this redirect after the "RewriteEngine On" part of the .htaccess file and use a RewriteRule (mod_rewrite): RewriteRule ^onsite2/$ http://domain.com/ [R=301,L] RewriteRule ^onsitefocusedthanks/$ http://domain.com/club/ [R=301,L]

Check this thread out: Symptoms are so similar I'd be kind of surprised if it wasn't related

Taking another look at this after a cup of coffee. While I still have no idea what's going on in your site, here's another workaround you could try, though you'll first have to grab the latest version of ProcessVersionControl.module from GitHub. Then add the following to the beginning of the /site/templates/admin.php file: $this->addHookBefore('ProcessVersionControl::executePreview', function(HookEvent $event) { wire('modules')->get('Spex')->setActivePage(null); }); This resets the active page for Spex right before ProcessVersionControl renders it, which in turn should make Spex behave as expected in this situation. If this works, it's probably the cleanest you can get without modifying either Spex or ProcessVersionControl manually (neither of which I'd recommend doing). Hope this helps.

Just wanted to confirm this. I have never gone quite that far myself, but I've found out that Facebook will skip the og:image property completely unless you specify og:image:width and og:image:height with it

Thanks for the update, @SteveB. Like I said, I've never really used Spex, but this change made the bundled example site work as expected. I'm curious about why _init.php wouldn't be loaded at all in your case and why it got loaded in my tests, but then again: it's not a huge surprise that a real-world use case doesn't behave exactly as a minimal example setup If you could provide me with a stripped down setup that doesn't work as expected, I could test this further, but until then I'm probably not going to be of much help here.

@SteveB: I might've figured this out. The problem is related to the way Spex sets up itself. It's a singular module and keeps track of the active page via a property called activePage, the value of which is defined the first time Spex is initiated. In this cases the first loaded page is the admin page for VersionControl. Spex sets that as the active page, and since it isn't meant for admin usage, this prevents some of the necessary methods from being triggered properly. The quick and dirty fix is adding the following to your /site/templates/_init.php file, before any calls to Spex are made: if (!$spex) { $spex = $modules->get('Spex'); $spex->setActivePage($page); } This is based on some quick testing on a module I'm not familiar with, so please take your time testing this properly, but so far it does seem to work for me. Another approach would be detecting Spex in the ProcessVersionControl::executePreview method, but to be honest I don't like the idea of adding module-specific workarounds there. From my point of view this is not a problem of VersionControl, but rather related to the way Spex works.