adrian

just try: roles=1015

Yeah, that does work but it does seem weird that the selector using the roles "name" populates the select options properly but just won't save.

I can confirm the same problem here although not sure why at the moment. As a quick fix, I discovered that it works if you use this: return $pages->find("template=user, roles=rider"); in the "Custom PHP code to find selectable pages" option instead. Can you please check that works for you? It would also be great if you'd consider posting an issue report about the custom selector option not working: https://github.com/processwire/processwire-issues

roles.name=rider

Great - I have pushed that version to Github.

Could you try the attached version (just replace this .module file). ProcessCustomUploadNames.module

@JoZ3 - sorry about the trouble - what version of the module did you upgrade from? That curly brace was added for PHP7, and I tested on 5.6, but maybe there is a problem with 5.3. I am sure I can write it a little differently to avoid the problem on 5.3, but just want to make sure that's definitely the issue.

Hi @Juergen - sorry, not sure about your issue, but looking at the contents of your page table, I couldn't help but think this new module by @BitPoet could be a much nicer replacement:

Latest version supports: Column selection and ordering for CSV export. Exported rows also respect the Find filters that have been applied. Should be very handy for clients to be able to extract relevant info from large table datasets.

Have a read about WireCache: http://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

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.