BitPoet

@ryan just commited my fix with a little type checking added, so the latest dev version from GitHub will behave nicely and clone _END fields to.

That line number hints at PW version 2.6 or 2.7. Have you tried with a recent release? If the error still persists, it's likely a version/configuration problem on your server. PHP 7 is a bit more opinionated about the return values of session handler functions, and older versions of memcache session handlers didn't always return strings where expected. So upgrading the memcache PHP module might help, or switching to regular file sessions in php.ini would be a workaround.

Keep in mind that the regular processInput method is still called afterwards, so any assignments to the page's fields will be overwritten by the submitted data. You need to fetch the $input argument from $event->arguments(0), read the submitted value from there and assign your computed value to $input["reservationdeadline"] (peek into the POST data in the developer console if you're unsure what date format to use). Don't modify $page, let the regular PW logic handle that part. Though you'd probably find it easier to remove the "required" option and run your logic in a saveReady hook.

and peeked again in the github repo to find that the setLocale part was added in 2017, so 2.7.2 won't have that (yet). So, yes, my line is likely a no-op.

I peeked into the setLocale method in Languages.php ($locale is fetched from the translation in wire--modules--languagesupport--languagesupport-module). } else if(strpos($locale, ';') !== false) { // multi-category and locale string, i.e. LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C foreach(explode(';', $locale) as $s) { // call setLocale() for each locale item present in the string if(strpos($s, '=') === false) continue; list($cats, $loc) = explode('=', $s); $cat = constant($cats); if($cat !== null) { $loc = $this->setLocale($cat, $loc); if($loc !== false) $setLocale .= trim($cats) . '=' . trim($loc) . ";"; } } $setLocale = rtrim($setLocale, ';'); if(empty($setLocale)) $setLocale = false; } LC_ALL=de_DE is a different case, as it contains no semicolon and is therefore passed verbatim as the value to setlocale.

XXX will be treated as an invalid locale and PHP falls back to the system's default locale (which is also used when the translation is empty). My line wouldn't be ignored, but unless there are any other functions using the locale, e.g. if you use a date format with weekday or month strings somewhere, there won't be any visible differences.

That de_DE could the culprit. You could try putting "LC_ALL=de_DE.utf8;LC_NUMERIC=C" (without the quotes) there instead (through the backend) to use German locale settings for everything but numeric things, for which the system's default locale will be used.

There's a translated string for LanguageSupport.module named "C" that holds the locale string passed to PHP's setlocale() function.

Well, since adding and deleting FieldsetOpen fields also affects the closing field, this is a little stumbling block. I've opened an issue with a suggested fix.

@theo: Thank you for the feedback, and I'm glad you like my module I'm going to look into that behavior as soon as I have a little time on my hands.

That's what OR-groups are for. $userTest = $users->get("(nick={$input->post->nick}), (email={$input->post->email})"); Btw., don't forget to sanitize your input before using it in selectors.

I just ran simple one-liners: REM Native mkdir REM ============ REM Default PHP 7.1: php -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test1/1/2/3'; mkdir($path, 0, true);" REM 7.0: "C:\Program Files (x86)\PHP\v7.0\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test2/1/2/3'; mkdir($path, 0, true);" REM 5.3: "C:\Program Files (x86)\PHP\v5.3\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test3/1/2/3'; mkdir($path, 0, true);" REM WireFileTools REM ============= REM Default PHP 7.1: php -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test4/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);" REM 7.0: "C:\Program Files (x86)\PHP\v7.0\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test5/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);" REM 5.3: "C:\Program Files (x86)\PHP\v5.3\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test6/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);"

This is one of the few cases where I don't care that much since getting the new CSS selectors isn't difficult, so I just make sure to document these small UI hacks in a dedicated place in the admin area. The format and styles plugins (as well as some other basic widgets that are internally realized as plugins) are already included in the main ckeditor.js.

It does work here (tested on PHP 7.1, 7.0 and 5.3) both with native mkDir and WireFileTools.

I've been looking for a solution to that years ago, and it seems the answer hasn't changed What I use as a workaround is to add larger styling for the combos in question with AdminCustomFiles, applying width and height to div.cke_combopanel__format and div.cke_combopanel__styles.

If tab1 is a FieldsetTabOpen, you need to use $template->fieldgroup->getField('tab1')->getLabel($language);

Why not set up the first site (or a kind of template site), run Site Profile Exporter, copy the created profile into the install package and run the regular installer with that profile for the subsequent domains?

What's the exact error you get?

Can you show us the output of SHOW VARIABLES LIKE 'sql_mode'; from MySQL? Which PW version are you installing / upgrading to?

Did you make some space in /tmp?

Try hooking InputfieldImage instead of FieldtypeImage.

If anybody wants to give it a try, here's a little attempt at an OR-group capable PageArray extension (just to see if this might be worth investing some more time and creating a PR). Usage: $regularPageArray = $pages->find("template=mytemplate"); // Returns an OrGroupsPageArray instance with the contents of $regularPageArray: $groupable = $regularPageArray->getGroupable(); $groupable->filter("fieldA=1, (fieldB=today), (fieldB=tomorrow)"); // or $filtered = $groupable->find("fieldA=1, (fieldB=today), (fieldB=tomorrow)"); OrGroupsPageArray.zip

Shouldn't that be addHookAfter?

Actually, you're right.

And append ->unique() to remove duplicates.