DaveP

Personal preference, I should think, but he also gave us (well, those of us skilled enough to take advantage) the tools to change that behaviour.

Definitely with @abdus on this one. PHP7 is noticeably faster than 5.6, and PW has no problems (that I'm aware of?) running under 7. If it is available, do it (taking the usual precautions, obvs). Also, there might be optimisations you could make to your selectors and there are probably mysterious optimisations you may be able to make to your mySQL setup, depending on how much control you have within your hosting. First of those you will probably get help with here, if you are able to share some code, second is down to black magic, voodoo and selling the soul of your firstborn. Or hiring an expert. All of that having been said, it's a very good looking website, and it works well - initial loading doesn't feel slow, just the filtering isn't instant. <edit>Man, 3 more replies while I write this one.</edit>

Just visited @apeisa's repo and found that I had forked it just over 5 years ago! (And lodged a pull request at the time.) Good job GitHub has a longer memory than me.

UIkit is still in beta (beta 30 at the time of writing). I should imagine that there may be more developments with the UIkit admin theme when UIkit comes out of beta.

Maybe people should be forking some of these kind of modules and breathing some new life into them.

I was just typing something along those lines when you posted. It's either that, or fix Spex, or refactor the whole site not to need Spex. (I figured out where the live site is, and I'm guessing that refactoring isn't actually an option.) You might find that the core PW stuff in the working version is still covered in the docs, since stuff is rarely (never?) deprecated completely, just new stuff added, and there isn't the imperative with PW to upgrade like you might be used to with WP. You can always come back here for advice - we usually try to help when we can.

Top detective work @abdus! It's worth a try.

Will probably break something else, but the other thread I linked to above was related to Spex. Unfortunately, that module's author hasn't been around since early 2016, it looks like. It might just be that the fix in the other thread works for you (fingers crossed).

Hi mike62 and welcome. Getting a 500 on your link. I assume the site was working before the attempted upgrade? And no errors during the upgrade? What modules are installed (/site/modules/) or Modules > Site in backend? (Might just be an incompatibility there.) Tracy debugger is highly recommended. If PW backend is functional it may be well worth installing. <edit>I just noticed Spex in the error messages - this thread may be relevant.</edit>

No problem. I've used it quite a bit, although not for the kind of stuff you're talking about at the moment. For anyone like me who's a bit sketchy on plain js, it's a great help and very powerful. It makes doing ajaxy search boxes and such an absolute doddle, cos PW plays real nice with ajax requests.

Others may come up with different suggestions, but intercooler.js (there is a module, but I haven't used it, even though I have used intercooler) can do infinite scrolling and history.pushstate. (And a load of other clever stuff, but they're your main two.)

https://moz.com/blog/structured-data-for-seo-1 Seems to me that one of the huge advantages we have with PW is that it's fairly straightforward to include 'extra' stuff as part of our rendered markup, without necessarily waiting for someone else to develop a plugin of some kind, as is so often the case with other CMSs. This blog post (and Pt 2 when it comes out I expect) not only goes into some depth on its subject, but links to loads of other resources on the topic.

It's good practice to use this any time you have a container of limited width and content from an external source (like comments or an RSS feed) or perhaps where a content author may include a link, which can often be long enough to break a layout.

Any reason for using a repeater? (Image fields can hold multiple images anyway, and much easier to manipulate.) See

This one comes with quite a pedigree, though - https://design.cms.gov/

And completely crashes my 2007 iMac at work. Which isn't a unique experience... Note to Self - Next time you change jobs, get one where they have up to date hardware.

Think t Just making sure. Think maybe there may be some mileage in http://schema.org/MusicRecording as well.

Just so we are all on the same page of the hymn sheet here, what exactly do you mean by 'metadata'? If you mean page metadata i.e. in the source code of each page of your website, then fair enough, but that is no guarantee of improving your search results visibility. If you mean something else, then please explain.

Just trying to save you the head scratching I had to go through to get even that kind of rudimentary understanding!

@abdus is absolutely right. Just to expand a little, what is happening when you do that is saying to PHP 'in this file the variable "item" to be treated as "ProcessWire\item" (for example)'. That means that if you were to find some code on e.g. GitHub that you wanted to include(), so long as it is namespaced, it can use an "item" variable (which will be treated as e.g. "ClassName\item") and can't conflict with your "item" variable. I'm currently developing a personal site that uses an image processing library I found on GitHub and it was fairly straightforward (even to a thickhead like me), to sort out the namespacing stuff, thus ensuring no naming conflicts. FWIW I thought namespacing was an unnecessary faff when Ryan first started on PW 3.n, but having seen the benefits, and considering the only downside is one extra line of PHP at the top of every file, it's not really worth leaving it out.

I didn't know that. It's obvious when you do, but when you don't... I thought it was stored, like in $session or something. It's been tripping me up for ages - using a delayed/deferred output strategy, things need to be called at different times.

Ryan has hinted in the past that he is aware of some major (global/multinational) sites that are built on PW but that don't advertise that fact. And of course PW doesn't have a front-end fingerprint like many other CMSs. Also take a look at https://processwire.com/about/sites/categories/education/.

Just a few random thoughts... From what I can see, your code is very much heading in a good direction - splitting the task into manageable chunks is IMHO a good way to go. I assume your product names are in German, based on your location. If so, AFAIK you may not be able to use some of the cool stuff available for English like mySQL's SOUNDS LIKE (bit of discussion here). How many products is 'just a few', BTW? One thing to consider is making your product search AJAX powered. Then users can see instantly if they are finding products or otherwise, and you can kind of 'lead' their searching efforts. (One easy way is intercooler.js - see http://intercoolerjs.org/examples/activesearch.html. There is a PW module.) A small thing that I have found useful in the past is to proactively deal with common misspellings - see and the rest of that thread. (YMMV)

Absolutely - Google is quite often wrongly thought to be the enemy. Not at all, unless people are trying to cheat in some way. They actually do their best to understand broken site architecture, which is something that PW does a great job of helping us avoid anyway. And we can easily go for a belt & braces approach by adding <link rel="canonical" href="<?=$page->url?>"> in our site's <head>...</head>, letting PW handle it. (Might very well be unnecessary, but can't hurt.)

That's the whole thing in a nutshell. Don't sweat the tiny details FWIW I don't think of the 'duplicate content penalty' as a penalty per se, more a discounting of the value of any content that is identified as a duplicate of some other content that is counted. If there is a negative, it's that it costs your crawl budget. By which I mean that say Google is prepared to crawl 10 pages of your site per visit, if 2 of those pages are the same content under very slightly different URLs, you are blowing the opportunity to have another actual different page crawled. Having said that, and getting back to the point, there are any number of more significant things to be spending time on.