BitPoet

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.

Yes, OR-groups unfortunately only work for database searches, not in-memory operations on PageArrays.

@oma: Like @kongondo, I'm not completely sure if I'm getting your question right. Are you, perchance, looking for or groups, i.e. a way to tell the filter "return all events that fulfill the other criteria and are either today or next month"? In that case, you need to still use commas but surround the individual selector parts that are sufficient for a successful match with parenthesis. $events = $pages->find( // Basic selector for all events not yet ended "template=events-detail, events_detail_dates_final_date>=$today" // First OR-group, today's events . ", (events_detail_dates_upcoming_start_date<=$now)" // Second OR-group, events next month . ", (events_detail_dates_next_month_start_date<=1519844959, events_detail_dates_next_month_end_date>=1517512159)" ); This would get all events-detail pages not yet ended and - sticking to your example and using parenthesis to outline PW's syntax - either (running through today) or (running next month).

This means that your MySQL server is in strict mode regarding group by expressions. MySQL used to be rather lenient there, but normally standard SQL requires that you name all non-aggregate (SUM, COUNT, AVG etc.) columns that appear in the SELECT clause also in the GROUP BY expression. Since along version 5.6, the ONLY_FULL_GROUP_BY settings was enabled as a default, and nowadays many hosters and Linux distributions also set this flag in installations of 5.5. Your "SELECT *" include the columns id, member_name, member_id and member_score, so for MySQL it looks like: SELECT id, member_name, member_id, member_score FROM golfscores GROUP BY member_id LIMIT 0, 1000; To understand why MySQL complains, you have to understand what MySQL does under the hood: It scans through the member_id column (or its index) for all unique values. For any of the other columns, since they aren't in the group by, it picks the first value it finds in a row found in the first step. This means, in your example data, it might find a member_score of either 30 or 38 for member_id 222. Which one it finds first and returns is pure chance. Since the SQL standard desires predictability and doesn't like chance at all, such a behavior is unacceptable. Very few databases allow such a thing at all. On the other hand, if you, as the developer, know that mismatched rows like in your example cannot be found in the database (i.e. only one combination for id, member_name and member_score is in the table for each member_id), grouping just by member_name tells MySQL "don't worry about checking uniqueness and order of the other columns, just return the first hit for each member_id" and saves the database server (sometimes quite) a bit of lookup work for those columns. This is, of course, a bit dangerous. Thus, the ONLY_FULL_GROUP_BY setting was switched on at some point. You can switch it off per connection, or globally for all new connection through a SET statement, but these won't be persisted (PW does this every time it initializes a database connection). If you want to use that optimized group by syntax, the best way is to do it in my.cnf (the server configuration). Somewhere there, you will find line in the [mysqld] section with the sql_mode. Remove ONLY_FULL_GROUP_BY from that line. /* MySQL < 5.7.x */ sql_mode = NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY /* newer MySQL */ sql-mode="NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY" Make sure to keep the format (underscore vs. dash, no quotes vs. double quotes) the same and restart the server.

Looks like your tmp (root if not a separate drive) partition is running out of space (error code 28 = No space left on device).

@OLSA: Thank you for sharing this. I have a built a few array field types before and also thought about using an approach like the Events field type, but the problem with that is that I'd have to create a distinct type for every group of fields and change the module's source code whenever the format of its "row" changes.