BitPoet

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.

Try adding this in site/config.php: $config->dbSqlModes = array( "5.5.0" => "remove:STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY" );

If the CustomerCode can be identical, you're likely creating identical names within a second. In that case, I'd add a simple counter to the page name seed.

Thanks for the feedback. I feared that the repeatable stuff has to be hand wired. I'm counting on being able to use the save to page feature, so I'd have to add pushing these fields' values into repeaters myself, and probably also add an indicator to make field groups as repeatable in the form editor and enhance the field mapper to include repeaters... I have to meditate on that

I'm considering purchasing FormBuilder for out corporate intranet to re-implement a decent number of forms. I've got a solid (albeit optically a bit outdated) form template solution that I built 12 years ago (I love seeing that number) and integrated into PW at some point. Since I'm up to my neck in work (and going to be that for quite some time), FB could be a means to quickly offload some work to colleagues since the old solution has text based templates and thus a bit of learning curve. A lot of our forms will need repeating rows, though. Thus, the question: does FB support repeaters (text/number fields would be enough), or some other type of repeatable field groups?

I can confirm now that IFTTT works with GitHub's atom feeds. Just got a bunch of mails in my inbox

Glad to hear Then all that's left is a webserver or hostname lookup configuration issue. Probably related to IPv6. Disabling IPv6 in the web server may be enough to fix this.

Haven't seen that before. Any browser adddons that may mess with the backend js? Any errors in the js console when the issue happens?

I don't think so. But I believe that you don't have the exactly same setup as @SamC, in which something, somewhere (a module, a prepend file, site/ready.php, whatever), already retrieves the children once before the code we see is executed. It's the only thing that makes sense. If you repeat code 2 in your test script, you'll get an output starting with 1|1|..., I'm pretty sure of that, so you can see the how, just not the where.

Yes, this is somewhat unexpected behavior and can be replicated with a short piece of code: $r = $pages->get('/'); $x = $r->children; $y = $r->children; $z = $r->children->prepend($r); echo $x . PHP_EOL; echo $y . PHP_EOL; echo $z . PHP_EOL; This outputs here: 1001|1005|1025 1|1001|1005|1025 1|1001|1005|1025 This illustrates that consecutive calls to children() return a pointer to the original PageArray while the very first call returns an independent copy. That's likely a caching thing, though I can't say if this is expected behavior. Tested with different versions of PW.

The title field is a multi language field, not a language alternate field. The id of the HTML input element is of the format Inputfield_[field name]__[language id] (Example: Inputfield_title__1013). You can see the language id in the address bar when you edit a language. In the showIf condition, enter that HTML id without the Inputfield_ prefix, e.g. title__1013!=''

On the dev tree it is. Ryan usually incorporates fixes there as soon as he has them ready without bumping the version number up. You can spot that when you look at the commit history.

@LAPS: I just tested it with a stock 3.0.62 (basic profile) in different browsers and the module works there, so it's likely some leftover / failed cleanup from an older install. Can you uninstall the module in the backend and make sure that you don't have any pages named "mention" in the page tree under Admin? If yes, just delete it manually. Also, please check that you don't have an older module version lying around in the InputfieldCKEditor directory. Then, best download the very latest version (0.0.70) from the github repo and install that. Don't forget to copy plugins.js into the correct path, and best clear your browser cache. After installing the module, you should see a page titled "Mention Autocomplete" in the page tree under Admin.

@fbg13: Good point, thanks. I have incorporated that. Makes the code a lot shorter too

You can always edit the original post and put "[solved"] in front of the title.

Update: settings can now be changed on per-field basis on the fields' "Input" tab. Latest version is on github.

@LAPS: thanks for the feedback. I'm not sure how the redirect comes to be and need to ponder that and perhaps run some more tests. What PW version are you on? Do you have languages active? The positioning issue has meanwhile been fixed. This isn't necessary. The .module and .css file are fine in their own module directory underneath site/modules (and keeping two copies under site/modules is like to lead to trouble). It's just the plugin.js that needs to go into the InputfieldCKEditor/plugins/pwmentions path so both the editor and PW can pick it up. I'm not sure client side caching is much of an issue, as every keystroke will change the result list and the unfiltered list might be far too long to download. I usually only do that with decent sized lists when I perform client-side filtering.

Since I was stuck to my flat today I took up a wish and rolled a Process module / CKEditor plugin combo that adds @-autocomplete like the mentions here in the forum to CKEditor fields. It's configurable, but only in module settings for now, the positioning of the select list is quite off and there's still some visual work to be done, so it is in early alpha state. Nonetheless, if you want to take a look, here it is: https://github.com/BitPoet/ProcessMention After installation, you may want to look into the "Additional selector" entry in the module's settings. You will most likely want to limit results to certain templates there. Edit: Updated to version 0.0.30 with fixed positioning of the dropdown. Edit2: Settings are configurable in field context now. If pwmentions is enabled, the according settings are shown on the "Input" tab.

Very, very alpha but working: https://github.com/BitPoet/ProcessMention

In that case, you almost definitely have a mixture of versions in your wire directory. It would probably be easiest to rename the wire directory on the server, re-download 2.6.18 from github at https://github.com/ryancramerdesign/ProcessWire/archive/8964c2d0b5f7d3445adcc5d91467f6117ef0d4fb.zip and upload just the wire directory (make sure to backup the db, though).

The mixture of namespaced and namespaceless class names looks a bit worrying. Might be an incomplete update (through FTP?) since InputfieldPassword seems to be namespaced but Functions.php not. I'd download everything to a local machine, get things running there, update that copy to a halfway recent PW3 version (>= 3.0.33) and see if that helps.