BitPoet

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.

It's a little bit more involved that just "opening a file manager on a URL", since you have to get the necessary information back to PW, tell it to download the image in question and add it to a page field. Here's a small module that can do that, but it's little more than a starting point (no checking of that image is already there, for example, no live updating the image fields in the page editor) and that requires a rest api plugin on Zenphoto's side.

The short answer is no. The longer answer is: you could add a hidden date field on the parent template and a save hook for your child template that updates the parent's date field. Then you can sort your parents by that hidden field.

@psy You're welcome. I hope you find something. Sometimes, a little break is exactly what one needs to spot an issue. Have a nice evening.

That's really, really curious. Is there any other code in site/(ready|init).php or _init.php that might be the culprit? Perhaps even stale code, so deleting site/assets/cache/FileCompiler and testing again might make sense.

Does putting $page->path in double quotes change anything? Does the network tab show any requests going on with a 404 return code when all other browser tabs are closed?