LostKobrakai

Also the name "for-page-1" suggests it's a repeater page, but somehow not in the place it's supposed to be in.

There's a part in the default .htaccess you can uncomment to automatically redirect everything to https://. I'm not sure you'd need to do anything else.

I'd use a key in the session of the user or a cookie. The url option is also possible.

You cannot rename the default language's name, just the title.

If you detect an user, who you want to see the english content, just redirect them to the www.website.com/en/. Everything will be automatically be translated on that page. You should almost never have to retrieve language values on your own besides in some edge cases.

Everything that's static text as part of your theme/template/page-layout should be put in code and be (optionally) translated. Everything which is content (a.k.a. the dynamically filled in data) is part of some page and therefore using multi language fields. Your example of a navigation is in my opinion the gray area in between. It can be static enough to be hardcoded, but it can be as dynamic as to use multi language page titles or alike.

There's no automatic translation anywhere. You'll still translate those texts in the backend, just not as part of a page in the pagetree, but as standalone translations.

Take a look at this section of the multi-language docs: https://processwire.com/api/multi-language-support/code-i18n/

There's not really a way to reliably detect an overall first visit to your website. You could however use the session and store some key or really anything by which you can differenciate between first visit (redirect) and later visits (no redirect) while the session remains active. Or you could use a cookie, which could even outlive the session of an user.

Or rather not do that, because it would mean uselessly loading pages. $count = $pages->count("template=$template_has_title, has_parent!=2, title!=''");

$swamp = $pages->get("title=Swamp, template=habitat"); $swampAnimals = $pages->find("template=animal, habitat=$swamp");

A parent/child relationship is no different than an exclusive one-to-one relationship with a page field. It just comes with the benefits of additional api support. The url is also to consider, but there are ways to work around that as well. So it boils down to your decision if you have a "primary" category you'd like to enforce (no child without parent). The demo page thinks it's primary enough for skyscrapers to be managed by city first and everything else later. This is in that case also shown in the url: http://demo.processwire.com/cities/new-york-city/chrysler-building/

Take a look at this one:

@Robin S It wasn't my intend to talk that much about separation of concerns at all, but about the fact, that people new to ProcessWire need a system which is first and foremost clear to grasp. This new region syntax is in my opinion the opposite. It might work for the tutorial type of situations, but I'm not sure it'll hold true for much beyond that. My biggest issue with it is that it's keeping it's state without any clear indication of what's happening. Someone who didn't read the docs on this feature or maybe just skimmed it lazily won't be able to tell why things happen as they happen. And that's probably the average guy or gal out there trying out ProcessWire for the first time; clueless of any of the magic id matching happening in the markup. The older function-based implementation of the regions api is way more explicit in telling even the clueless reader of the code that stuff is being placed in some kind of regions, which are later printed in the wrapping markup. My addition of "separation of concerns" as part of an educational piece on templating was just for it's own sake: education. I see lot's of code examples around the forums, which are just a mess of business logic mixed with view logic mixed with html markup. Such code is a nightmare if the client comes around and asks you to change some things here and there. Even better if things should later be used in multiple different places. It would be a shame to leave those issues out when discussing the differences between templating strategies in processwire.

I'm not sure it's worth looking into. Caching for backends is imho not the best idea to start with, so at best Ryan could mention it somewhere as "known issue".

There's probably some html markup between those in the template.

<?php $subpages = $pages->find("has_parent=/deals/, template=subpage, sort=-publish_date"); foreach($subpages as $subpage): ?> <?php echo $subpage->deals_category?> <?php endforeach; ?>

There's isn't a one field solution for your problem so yeah, simply hide the integer field if someone selects unlimited.

// Returns 10 pages, which are then further filtered, so it could even be none $lastEvents = $player->get("name=history")->find("template=event, sort=-date, limit=10")->not("task.name=donated|donation|absent"); // Returns 10 of the correct pages $lastEvents = $player->get("name=history")->find("template=event, sort=-date, limit=10, task.name!=donated|donation|absent"); Not sure what behaviour you want there, but there's a difference.

You could, you only would need to calculate the start value for $pages->find() manually.

Try to delete /site/assets/cache/FileCompiler and the cache table in the db.

Maybe you can adapt this to work as you need it:

You can take a look at the /wire/config.php about new config properties, but there shouldn't be any you need to use to run 3.0.

A textformatter would be the way to go if these button classes are subject to change (and most often they are). So you can easily just update the textformatter and everything will still work even for older texts. It's always good to keep html in the database as generic as possible so it's not going to cause problems if things change on the frontend.

The reason is quite simple: $pages->find() is not using viewable(). Only findOne seems to be using it. If you need access contraints on the database level have a look at DynamicRoles.