teppo

If the error occurs in Admin, it has nothing to do with your templates. It also shouldn't have anything to do with FileCompiler: you're running 3.x, so core files don't need to be compiled. Did you upgrade via git pull or something like that, or replace the wire directory manually, or how did you perform this upgrade? There's a slight chance that something is missing from the /wire/ dir, so one option is to remove and add it again (note that if this is a live site, the pubic site won't work at all while the wire directory is missing). Another thing would be checking that file permissions are fine, and make sure that the module you're trying to open works as expected. By "the module link is not working" you meant that you're trying to open the page related to some specific Process module, right?

Thanks, @BitPoet I'll take a closer look at the code changes soon. Meanwhile I've created a new issue to the ProcessWire repository regarding UserGroups issue #45 and the related change in the ProcessWire core. I'd like to hear what Ryan thinks about that before implementing any kind of fix for that.

Nope, nothing on this side either. Should find some time to test this soon.

@tpr: finally found time to take a closer look at the language tabs issue. So far there appear to be two issues behind the scenes: VersionControl stores all language values in the form of "data[language-id]", but the field name for the default language is actually just "data". I'm pretty sure this used to work at one point, so perhaps it was a core change somewhere between 2.4 and 2.6 (have to setup a test site with earlier version to make sure). When built-in language tabs are enabled, CKEditor instances are not loaded before a specific tab is opened. This is a bit of a problem, since I can't set a value of a CKEditor instance unless it's already there. This requires a bit of testing, but I'll try to get these sorted out soon.

Out of interest, which product are you referring to and/or how does one gain access to this free plan? The sign up only speaks of a 14 day free trial, and I can't seem to find this option on their site either I gave their application monitoring a try something like a year ago. Seemed really interesting, but sadly (at least at the time) it wasn't working too well for ProcessWire: knowing that most of my users interact with index.php or that index.php is eating the bulk of my resources wasn't exactly what I'd call "insightful"

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]