dragan

If you don't need the entire page arrays of $shipments, then only querying the counts will always be way faster. Also, try to use findMany() instead of find(). I just ran three queries on a dataset of ~1100 pages in Tracy, and got an average of ~34ms: <?php $sel_2 = $pages->findMany("parent=1041, template=project, created>$month, include=all")->count; $sel_3 = $pages->findMany("parent=1041, template=project, created<$last2Years, include=all")->count; $sel_4 = $pages->findMany("parent=1041, template=project, images.count>0, include=all")->count; d($sel_2); d($sel_3); d($sel_4); Using just find(), it was about 10x slower. Or you can even replace find() with findIDs: <?php $sel_2 = $pages->findIDs("parent=1041, template=project, created>$month, include=all"); $sel_3 = $pages->findIDs("parent=1041, template=project, created<$last2Years, include=all"); $sel_4 = $pages->findIDs("parent=1041, template=project, images.count>0, include=all"); d(count($sel_2)); d(count($sel_3)); d(count($sel_4)); This takes it down to ~20ms, i.e. approx. 33% faster than findMany()->count Of course, if you have a really huge amount of pages, then a real direct DB-query (avoiding PW's API) will always be the fastest option. Or try @bernhard's RockFinder module.

You should be able to translate these strings in the language section: setup/language-translator/edit/?language_id=1010&textdomain=wire--core--wiredatetime-php Just replace the language_id with your alternative language id. Or go to setup > languages > German and click on "find files to translate" under "core translation files", then select WireDateTime.php.

@fruid I guess the only way to circumvent this behaviour is to delete with the backspace key, instead of "select block and use delete-key". Searching for this issue brought up this PR, which apparently has just been merged yesterday (though I'm not 100% sure if it really fixes the exact same issue).

@DanielKit Did you also check the JS console? Maybe you'll find some useful hints in one of these old forum threads: https://processwire.com/talk/topic/11627-pw-admin-logon-problem-on-php-7-platform/?do=findComment&comment=108209 https://processwire.com/talk/topic/4211-unable-to-log-into-admin-session-write-issues-using-vagrant/ https://processwire.com/talk/topic/5183-cant-get-processwire-working-in-vagrant/

As @kongondo already mentioned, you can get the unformatted value, and then simply do all the desired calculations you need. $ts = $pages->get(12222)->getUnformatted("proj_timespan_to"); $diffHours = (int) round(abs(time() - $ts) / (60*60)); $diffDays = (int) round(abs(time() - $ts) / (60*60*24)); You'll find plenty of documentation about PHP functions, e.g. here or here.

try something like this: parent=page.parent.parent, include=all

That's something that for whatever reason stopped working for me as well, since a few weeks / months. Don't know if that has been reported as a bug though.

I guess inside a module you have to use wire('languages')->setLanguage("foo") instead of $languages (not sure, no time to counter-check). Nice one... didn't know that method existed like that. Well, that's certainly even better. The wonders of the PW API never ceases to amaze me 🙂

If you don't need the PW API to process the form, you can place your script in root. action="<?=$config->paths->root . 'myscript.php'?>" Although, as already mentioned, I'd suggest to create a PW page + dedicated template for such stuff. Together with URL segments, you can place all your form processing logic in one single file (or even include() each sep. form processing logic, in case there's many of them). Well, actually URL segments aren't really needed, you can just as well include a hidden field in your form, or add a ?form=support to your action URL. Many ways to skin a cat 🐈

The easiest way to make sure you always populate the default language, is a one-liner before all your regular page-creation functions: $languages->setLanguage("default"); and of course, if you always explicitly want to edit the french value: $languages->setLanguage("fr");

You don't need a hook for that. Just render the page title in your frontend template dynamically. Maybe something like this: $pageTitle = $page->title; if($page->template === 'product' && isset($page->design)) { $pageTitle = $page->design->title; } ?> <title><?=$pageTitle?></title>

@MSP01 I'm no expert on PW's auto join, but re: 2.) I think PW will definitely fire SQL behind the scenes each time you use such a helper function. What you could do instead, is maybe create your own $config vars. That's a perfect use for global settings, e.g. image resize options, or define your own custom paths/URLs etc.

I'm having a Case of the Mondays™ today... I've been using PW now for some 7 years or so, and most sites were multilanguage setups. Today I was trying to "upgrade" a PW site and add a 2nd language, and everything works as expected, except one strange thing: The default pagetitle field (id 1) only shows up in the page editor with default input language field. If I switch from german (default) to english in the admin, I see the english titles just fine in the page tree. However, when I open a page (any page, any template), I only see the german field, without the UI folder icon, or tabs). The API correctly gives me the language values I'm expecting. I thought maybe I wrote a hook a long time ago which causes this behavior, but I disabled my site/ready.php altogether, and things are still the same. Does anyone have a clue where to look, and how to debug? The UI elements are not there when I inspect the field in the browser (i.e. they are not just hidden by CSS, they're not there). What module or config could possibly cause this? And it's ONLY the pagetitle field that is screwed, all other text- and textareafields work fine. Update: I had a "pseudo multilang" field title_en, which caused havoc. Once I renamed (and finally deleted) this field, everything wente back to normal.

This may seem like a hackish workflow proposal, but you could just as well clone the production page, unpublish that copy, and work on that. If the clone is ready to be published, publish that one and hide / unpublish the other. Just bear in mind to adjust the page names and -names to avoid ugly looking URLs like /section/my-page-name-copy and 404s.

Another good reading material: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/