dragan

@charger If you're looking at the JS in Chrome inspector, you'll see , le = new ue("https://architekturfuehrer.koeln/api/v".concat(ae.API_VERSION, "/"),{ objects: { path: "objects" }, object: { path: "objects/{identifier}" }, taxonomies: { path: "taxonomies" }, walks: { path: "walks" }, pages: { path: "pages" } }) , he = new ue("https://architekturfuehrer.koeln/",{ magazin: { path: "magazine/results.json" } }); These are simply JSON that store all the necessary infos, e.g. https://architekturfuehrer.koeln/api/v1/objects See the OP under "Backend", 1st paragraph.

Googlebot is clever these days. JS-content is no problem for indexing anymore (React, Angular, Vue etc.). Meta tags and page titles are adjusted for every page-view (something a lot of developers simply forget when building SPAs). Of course, you could always improve SEO, e.g. creating a sitemap.xml... https://www.smashingmagazine.com/2019/05/vue-js-seo-reactive-websites-search-engines-bots/ ^ a good read about the subject

I read your OP now 3 times, but I'm still not sure I understand the big picture of your "code" usage / need. The most simple solution (unless I'm overseeing something) would be to use page IDs. Since every product is a page and hence has a unique ID, and every light source is a page too, you could construct a code like e.g. P1234LS5001_5002_5003 P = product (page id 1234) LS = light source(s) (page ids 5001, 5002, 5003) instead of _ you could use any other delimiter of course. That way, you can easily identify the "owner" (product) and the "attached" light sources (regex, substr etc.). Instead of page IDs you could also use page-names instead, but IDs are usually more future-proof. PS Is the ultimate goal to create URLs that automagically "assemble" the product with all parts? Did you consider using URL-segments? You could use something like mysite.tld/products/product-page-slug/lights/5001/5002/5003/

Well, you would first check if the IMDB fields (content) is identical to your already existing page content / fields. If not, skip the update. If one or more fields don't have matching values, update the PW page field(s) that have changed.

Sounds great. The less opinionated, the better ? To answer your original question: SPA profile (Vue, React, Angular or whatever is "cool" this season) Headless profile (perhaps using GraphQL or a simple REST for the frontend to quickly grab content and assemble whatever you wish) PWA profile (service workers, Cache API, a frontend setup showing how you can build pages that can be used even when offline - "app shell" philosophy) "pure awesomeness" starter profile that has the coolest modules already pre-installed, like Tracy, BCE, AOS etc. (the actual choice is of course highly debatable). This would - in a nutshell - show the combined power of what's in the core already - and then some.

What's in the root folder? Another PW installation? Or someting else? What are the index.php/.html and .htaccess of root? If you installed PW into domain.tld, then of course that PW homepage will be shown in domain.tld/subfolder/, not domain.tld/

you could try something like: $search_options = $templates->get("project")->fields; $fieldNames = array(); foreach($search_options as $so) { $fieldNames[] = $so->name; } sort($fieldNames); afaik, $search_options is an object, not an array.

Well, well, well. I don't even know where to start. Speed is a big factor, and you should always strive to optimize for it. People on spotty, slow mobile networks might beg to differ with your opinion. And Google too. In case of a typical single page website, you could at least implement some sort of lazy loading technique, which would at least optimize the perceived loading time. Also, run Google Chrome's Lighthouse speed audit, and you'll spot some strange problems there related to the site's images.

https://modules.processwire.com/modules/inputfield-simple-mde/

sure

I'm not sure, but take a look at this: https://modules.processwire.com/modules/markup-simple-navigation/ -> hook for custom item string (new in 1.2.0)

Is it a brandnew site? It might take a few days, if you just launched. That's nonsense. You don't even have a robots.txt file ? You probably mean .htaccess - yes, there's a huge block where all kinds of paths are forbidden to show the index (file list). But that hasn't got anything to do with your issue. But you have a sitemap.xml in place, that even lists images. Looking at that sitemap.xml actually puzzles me. You have no (visible) page /tapas, only #tapas on root. Since you have a one-page site, you have to somehow adjust the setup. Either turn #foo into /foo or adjust your sitemap.xml somehow.

You probably didn't adjust this line: I assume each of your categories is a page, i.e. you are using page references.

// we are only using 1 URL segment, so send a 404 if there's more than 1 if(strlen($input->urlSegment2)) throw new Wire404Exception(); $segment = $sanitizer->pageName($input->urlSegment1); $categories = $pages->get(1192)->children; // 1192 = id of parent holding my category pages $allowed = array(); foreach($categories as $cat) { $allowed[] = $cat->name; } // does the URL segment match an existing category name? if(!in_array($segment, $allowed)) { throw new Wire404Exception(); } else { $results = $pages->find("id>1, template=templateblogpost, category=$segment, limit=5, sort=-postdate"); foreach ($results as $post) { // output each $post } } If you do it like my above example (or similar), yes.

Just use URL segments.

Hello @dandeckr! I'm sure you also stumbled upon the selector docs. Can you elaborate what you are trying to achieve? Do you need to do some complex queries? If you tell us a bit about your site structure, and what you have already done so far, I'm sure we could jump in with some practical tips. A simple NOT would mean simply using field!=value. There are also quite a few methods where the documentation is scattered a bit all over the place, e.g. https://processwire.com/blog/posts/pw-3.0.25/ https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support

Hello and welcome to the forum. You should edit your thread title... "Mr" is not very descriptive ? JSON support should be included in the core with every PHP installation, according to the manual. Check with your hosting company if they can enable it. The GD library is also very common. Again, ask your hoster to enable it. Or, if you are developing locally, and use something like Laragon, you can probably enable the extension with a few clicks:

180 I'm too tired right now to look at each and every single query, but I'm puzzled by a few randomly spotted queries such as SELECT false AS isLoaded, pages.templates_id AS templates_id, pages.*, pages_sortfields.sortfield, (SELECT COUNT(*) FROM pages AS children WHERE children.parent_id=pages.id) AS numChildren,field_email.data AS `email__data` FROM `pages` LEFT JOIN pages_sortfields ON pages_sortfields.pages_id=pages.id LEFT JOIN field_email ON field_email.pages_id=pages.id WHERE pages.templates_id=3 AND pages.id IN(40) GROUP BY pages.id I don't need any email field in this page / template. So I wonder why is something like this even queried? I'm sure (or I hope) there's a good reason why this query is listed, but I'm just not sure why. (by Tracy, or PW core? or just PW core-while-in-debug-mode?) Still - to me, those timings are quite acceptable. And yes, if debug is off, it's even faster. (though I haven't set up a script to measure that - I just look at Google Chrome's performance audit results or similar for TTFB).

You can also edit your local HOSTS file, so the domains always stay the same. Just remember to comment your hosts file when working on the live site ?

Execution time 166.5 ms CPU usage user + system 20 % + 1 % Peak of allocated memory 9.55 MB Included files 230 OPcache 100% cached Classes + interfaces + traits 238 + 28 + 0 Selector queries 17 HTTP method / response code GET / 200 PHP 7.2.18 Tracy 2.5.6 Server Apache/2.4 number of fields in this template: 40 (overall, maybe 70) Tracy enabled + debug mode on I would maybe take a look at some server-level optimizations. Or try the same install on another environment.

I was using one of the demos from the UIKit site and didn't really change much, apart from inserting text instead of images, and the a.m. CSS bit. PW doesn't care about any of your frontend code. It will render anything you want. There's plenty of ready-made sliders that support auto-height, here are just two random examples: https://owlcarousel2.github.io/OwlCarousel2/demos/autoheight.html https://codepen.io/simonmshirley/pen/remoXb

I'm confused. Do you want to fetch data from a remote URL, another site? Or from another PW page in the same installation? I guess you could use CURL or WireHttp. Not sure you need a separate page under admin though.

Another (rather lo-fi) setup could be: Use dev template files, as alternative templates. For testing out new content, you can leave pages unpublished and still preview them when logged in. If your client (role) has permissions to switch templates with Tracy Debugger, there the template switcher panel you could use. https://processwire.com/blog/posts/introducing-tracy-debugger/#template-path-panel https://processwire-recipes.com/recipes/use-different-sets-of-template-files/

Well, there's a plethora of PW sanitizer methods: https://processwire.com/api/ref/sanitizer/ A good combo might be: https://processwire.com/api/ref/sanitizer/chars/ https://processwire.com/api/ref/sanitizer/min-length/ And of course native PHP has many methods you can use in addition to the PW API functions (some of them are just wrappers or combinations of native methods).

Oh, don't worry, I always do that, in addition to all sorts of user-input sanitation/validation. I was rather just speaking theoretically. Thankfully, PW code in the site profiles has plenty of useful examples with comments, which will hopefully prevent newbies to omit such checks. After all, we can't expect PW to handle everything for us; it's always up to the developer to take care of security and best practice.