DaveP

Just tested this on a PW site I'm currently developing, and which is using default settings for slashes etc. Using Chrome extension Redirect Path to confirm, PW does indeed redirect @szabesz's example 2 (no trailing slash) above to example 1 (with trailing slash), with a 301. Hurrah!

Just a couple of observations. It really doesn't 'hurt' anything to have high numbers of pages - they are only database rows after all (slight oversimplification). It might feel wrong or clumsy coming from other CMSs, but PW is more flexible. As far as a selector for recent news items, bear in mind that you can pass any string that can be parsed by strtotime() to a date selector so something like $latestNews = $pages->find("template=mini_news,created>='-18 hours'"); will return a pageArray of all items created in the last 18 hours, which you can manipulate further if necessary. The advantage of using a 'real' page for things like this is that you have all the flexibility that comes with that.

I suspect that what is actually happening is that the 'normal' browser and 'incognito' mode are caching two different versions of the page, the 'normal' probably being older. Try a completely different browser and see what happens. BTW you could also try changing your code to $meta_title = $page->get('meta_title|title'); which should do the same thing. (Coz that ternary is hideous and unnecessary ) This won't actually help with the current problem, but is much nicer code.

It's not unknown for nasties to masquerade as legitimate files/folders (Windows has long seen viruses & malware processes pretending to be svchost.exe, for example), but if you have installed a Let's Encrypt cert recently, it's probably part of that installation.

I think @cb2004 is right - see https://serverfault.com/a/795474/129338 (towards the end of that answer).

Great call, @dragan! And props to @Philipp (who hasn't been around the forum much lately) for the video. Although the video was done just over 3 years ago, and some things have changed a little bit, it is well worth a watch. (I'm watching it again now.)

How easy you find converting a static template for PW will depend very much on your experience with PHP. You don't need to be an expert, just comfortable using variables and a few loops. Take a look at the site profiles that come with the PW download, and see how they are structured. There are many different ways to organise your template files - probably as many different ways as there are PW users! Finding a system you are comfortable with is probably the trickiest bit. Take a look at this tutorial specifically, and try to work out how to apply whichever strategy you prefer to the template you have. <aside>I'm sure somebody did a video on converting a downloaded theme but I'm damned if I can remember the details. If no one has, then someone should.</aside>

It was set to 'No', but I've changed it to 'Yes'. Now I get the error on login as well. Having said that, the site (it is an intranet so every user has to be logged in) uses LoginPersist, so I have to log out intentionally in order to need to log in.

I'd just read @szabesz & @Robin S's replies, and went to reload the offending page, and got this... Yep. it worked. But only the once. Now it's back to the same state as my post above. Could it be some cache-related weirdness? If it works once it should work every time.

This may be a bit too obvious, but don't you need a regex:^delete/[0-9]+ entry as well?

Ok, I got that. Doesn't look much different to yours, or am I missing something?

@Robin S Thanks for your reply. I tried your snippet, but got nothing back. (Absolutely zilch - I even wrapped any output in asterisks to make sure something was happening.) Then I added echo $http->getError(); and guess what I got? Thanks a lot, Github.

The error only shows for PW repos (see screenshot). If there were a general problem, then surely the other repos would be unavailable too.

Done some more digging on this. Tried adding ini_set("user_agent", "PHP " . PHP_VERSION); to config.php. Didn't work. Found https://github.com/BitPoet/ProcessWireUpgrade/blob/dev-useragentfix/ProcessWireUpgrade.module and added $ua = ini_get("user_agent"); if(empty($ua)) ini_set("user_agent", "PHP " . PHP_VERSION); (Lines 101 & 102) to ProcessWireUpgrade.module, per @BitPoet's fork. Didn't work. I also added, as a test, <?php ini_set('user_agent', 'ABC'); echo ini_get('user_agent'); ?> to one of my template files and it did echo 'ABC', so ini_set() is working. So it isn't user_agent that is causing the problem.

Completely forgot the curly brackets. Virtual 'Cheers!'.

This should work $ctas = $pages->find("id=1|2, id!=$page->parents->append($page), sort=sort"); (Completely untested.)

<disclaimer>even less expert in this than other stuff</disclaimer> Can't see why not, in fact, since this thread was last updated, we now have e.g. ready.php, where IMHO it would be easy to put a bit of code to update a counter field. Filtering by user would be straightforward, and you could do something clever with $session to discount reloads, but bot user agent sniffing has always been something of a dark art. Jeff Starr has a probably-reliable list on his blog. (Warning - if you are interested in this kind of stuff, you could lose half a day reading there.)

You could try one or other of include=all and check_access=0 (see https://processwire.com/api/selectors/#access_control) in your selector, which may help with debugging.

Hi IvanSCM and welcome. This may be what you're looking for

Glad you got it working. Have fun.

Hi rushy and welcome. It sounds like your .htaccess file isn't working. Check that it has been renamed from /processwire-master/htaccess.txt to /processwire-master/.htaccess and if it hasn't been, try renaming it manually. If it has been renamed already, or after you rename it you still can't access /processwire-master/about/, open .htaccess in your preferred text editor and type some random characters at the top of the file and save it. That should get you a 500 error, which is ok, because it means that Apache is processing .htaccess. If you do get a 500 error, revert the changes and save it again. Then come back to the forum and we will try some more steps. <edit>Should have mentioned https://processwire.com/docs/install/troubleshooting/!</edit>

Hi Margie, and welcome. This error (and subtle variations of it) is one that keeps appearing, but only for some people on some hosting configurations. As a consequence, it still crops up now and again. One straightforward workaround is to copy the module files manually via FTP to /site/modules/ then visit yoursite.com/processwire/module/ and finish the install there (or upload a zip from that page). Not as seamless as it might be, but it does work (and was the only way back in the day).

If I understand correctly, that a successful form submission is then redirected to /thank-you/, I would use $session. Then you could do something like this <?php // Form A if($success){ $session->formSuccess = 'formA'; } // or 'formB' etc on any other forms // then redirect to /thank-you/ and then <?php // /thank-you/ if($session->formSuccess){ switch($session->formSuccess){ case 'formA': $message = 'Thanks for submitting Form A'; break; case 'formB': // etc } $session->formSuccess = ''; } else { //redirect to /home/ or wherever }

Don't know if it should be possible to do this or not, but one workaround might be to have a field on the page to hold the count, and update it automatically on page save. You can set the field (say awards_count) to not show in the admin, so it will only be maintained by a simple hook function. It's really easy to do... Add a new field awards_count to the appropriate template (I'll assume work based on your question) and set it to not show in the admin (Admin > Fields > awards_count > Input > Visibility > Hidden (not shown in the editor) Add a hook in /site/templates/admin.php something like this <?php namespace ProcessWire; /** * Admin template just loads the admin application controller, * and admin is just an application built on top of ProcessWire. * * This demonstrates how you can use ProcessWire as a front-end * to another application. * * Feel free to hook admin-specific functionality from this file, * but remember to leave the require() statement below at the end. * */ $pages->addHook('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); if($page->template == 'work') { $page->awards_count = $page->awards->count(); } }); require($config->paths->adminTemplates . 'controller.php'); And that should do it! Then you can do sort=-awards_count using the new field instead of the count property.

Don't know if other problems referred to above are related, but I'm having trouble in Chrome on OS X Yosemite, where, after uploading (and client-side resizing) a good number of images, there seems to be a memory leak or maybe Chrome not releasing memory or something. Sequence/symptoms are - Everything works fine for a number of uploads. Next handful of images seem to work - thumbnail is shown under spinner - but image saved is all black. Mac display starts corrupting and needs a restart to fix. Same image that didn't work above now works fine. This has happened a few times, so does seem repeatable. I'll do some more testing and try other browsers (haven't done yet), and if anything pops up I'll report back.