adrian

Big +1 for this - sometimes it can be very hard to explain what should go in a field without a label.

I'd obviously like to know more about this - could you help to narrow it down to a specific panel - use the panel selector to disable all panels and add them back in one at a time. Or perhaps even just look at the ms/kb values on that panel to see which the culprit might be.

That is weird - it's certainly working for me. I think the problem is the "...\" at the start of the path. Would you mind having a play around with the replacement code (https://github.com/adrianbj/TracyDebugger/blob/90d0fd95a5f7b77df044c4a66dc5bd01e97d41e5/TracyDebugger.module#L299-L311) to see if you can come up with a working solution. The thing that makes it a little complicated is that the Tracy guys stuck with my initial suggestion of strtr rather than going with my revised str_replace option which would have given much more flexibility since strtr won't replace the same substring more than once. What this means is that you must replace the entire path up to and including "FileCompiler/". Because yours is for some reason returning a relative, rather than absolute path, the replacement isn't being made. Unfortunately I don't have a Windows box to test on, so I think I will have trouble reproducing, although I think it might also be the way your server is configured. I would certainly like to implement a working solution though if we can get one.

Did you upgrade the upgrades module first? It's working here!

Yes, every file in PW has a db table to match its name prepended with "field". If there are no rows, then that explains why echo $page->siteviews isn't showing anything. Ton convince yourself that your echo is working, I would manually add a number to the siteviews field for a page (via the page edit interface in the admin). Then you need to debug why @LostKobrakai's: $page->set('siteviews', $page->siteviews + 1); is not working. Are you actually using that, or his pre-edit version?

No need to manually include site/ready.php What you want is: $page->siteviews because you are trying to get the value of that field for the current page. $pages->siteviews won't work at all because $pages needs a ->find or ->get to get the page of interest if you're searching for a page other than the current one ($page). Did you notice that @pmarki's code uses "visitCounter" rather than "siteviews" ?

You'll probably need to log out - that module only checks for new PW versions when logging in: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/10

The ?? is new to php 7 http://lornajane.net/posts/2015/new-in-php-7-null-coalesce-operator

Sorry Mike - looks like it was an issue with a recent change to the Tracy core. I have restored the core to an earlier commit and pushed a new version here which fixes the AJAX bar.

Beautiful and functional site and a fantastic writeup - congrats and thanks!

It's a very important fix though - I wouldn't want to break anyone's non ML site if they upgraded to the latest version of this module, so very glad you reported this.

Maybe I am missing something here, but aren't you causing yourself a world of extra pain by declaring a custom namespace (Site). Any reason not to use ProcessWire ?

Sorry about that - it should be fixed in the latest version.

That makes sense for sure with echo wire(config)->paths->templates; it should be: echo wire('config')->paths->templates; Not sure why you would get the undefined constant with the $config version though.

Thanks @szabesz - it should be fixed in the latest version. I also added a "*confirmed false" to the mod_security entry when we know it's definitely disabled. I am pretty sure this should be accurate, but would be keen to hear reports from you guys about this. If it doesn't have this "*confirmed false" text, and it is reported to be Off, we can't be certain because it's a sign that PHP is in PHP-FPM (CGI) mode and we may not be able to detect it. As far as I can tell if it reports it as On, then I think we can be certain of this no matter what mode PHP is in.

Yeah, maybe that would be more efficient, but wouldn't you also want to throw a 404 if it didn't match match your required range? Using a more specific regex in the "Which URL segments do you want to allow?" would take care of this automatically. I am no expert in the efficiencies of regex matching, but do you think it's worth having a simpler regex to save the additional checks in the code? I guess you'd need to test the two and see

Probably nothing wrong - I guess it depends on how determined you are to make sure they are valid years. Yes 9155 is a valid year, but it if was an accidental transposition of the 9 and 1, then it might be nice to exclude it if you are only expecting years plus or minus a hundred of today (or whatever is appropriate).

@szabesz - Thanks for the pointer to Tracy for this. Unfortunately, of everything in that list, mod_security is the one thing that can't be reliably confirmed as not installed, because PHP can't determine this for PHP-FPM - it only works if php is installed as an apache module. A positive "1" should confirm that mod_security is installed, but a false result unfortunately can't confirm that it isn't. I might add an additional check to show if the negative is confirmed - that I think we can do.

http://modules.processwire.com/search/?q=rss

Sometimes it's better to use the ID of the page for those critical pages, or employ some way to prevent changing the name of the page: page-rename permission: https://processwire.com/blog/posts/language-access-control-and-more-special-permissions/#how-to-use-the-page-rename-permission "prevent manual changes" option in the Page Rename Options module: http://modules.processwire.com/modules/page-rename-options/

Here's a nice article with some examples if you need to allow dates before 1900 http://www.x-note.co.uk/javascript-regex-validate-years-in-range/ Also don't forget about some of the great regex testing tools: https://leaverou.github.io/regexplained/ https://regex101.com/ http://www.phpliveregex.com/

But if you are already familiar with the destination and know that it is compatible, then that is still the easiest way to copy a PW installation. Perhaps the tutorial could include a caveat suggesting a test install from scratch might be beneficial if you are unfamiliar with the hosting environment. @Joss ?

Do the changes stick after you save, or are they reverted?

My guess would be that your assets/files folder doesn't have read permission. Do a quick recursive change (to get all the subfolders as well) to 777 to test and if that works, then sort out the proper owner/permission settings.

This might be a feature request. Similar functionality already exists for the Profields Table field: I understand diogo's suggestion, but surely this is not really a multi-language question, is it?