BitPoet

Do you get an error message? If not, perhaps you can spot something in the network tab in Chrome's developer console.

The problem is that anything that looks like a ctype_digit is coerced to int in Selectors::makeSelectorArrayItem, even if you use nested array syntax and pass in the name of a sanitizer method.

I've added a few details about the cause of the expection to the issue. In short, the pages.name table is created with an ascii charset by the installer, which should probably be changed. As a workaround, after installation, execute the following statement: ALTER TABLE pages MODIFY COLUMN `name` varchar(128) character set utf8 NOT NULL; (Change utf8 to utf8mb4 if you selected that character set in the installer)

The blog module uses PW's core Comments field type. You can either use its render() method and pass in templates that generate the desired output, or iterate over the comments yourself and assemble the HTML. All of that is explained in FieldtypeComment's documentation.

Then your server doesn't have time zone data installed. If you can add that, you can assign a zone name and don't have to adapt the offset every time DST changes. Glad to hear you got it solved though ?

What happens if you set the following in site/config.php: $config->dbInitCommand = "SET NAMES '{charset}', time_zone='Europe/Athens'";

I'm not sure if I can implement sorting directly in the database for advanced date parts, but you can sort in-memory. $result = $users->find("profile_birth_date.month=$mes"); $result->sort('profile_birth_date.day'); // $result is now sorted

Not really, unfortunately. At that point you can assemble the session name, but to retrieve the data associated with it, you have to invoke session_start.

This probably needs to happen inside an autoload module's constructor as module init / init.php is likely too late. Wire() is already available at that time. Here's a little PoC snippet: public function __construct() { $this->addHookBefore("Session::init", function(HookEvent $event) { // fill the data backpack with whatever you extract from the // external session: $this->wire('dataBackpack', ["some" => "thing"]); }); $this->addHookAfter("Session::init", function(HookEvent $event) { foreach($this->wire('dataBackpack') as $k => $v) { // set the retrieved data as session properties: $event->object->set($k, $v); } }); }

I don't think you can at that point. I'd just hook both before and after init, store the external data in a variable/property somewhere in the before hook, retrieve that data in the after hook and assign it using the regular Session::set method.

I couldn't replicate the issue here. Can you give some specifics about your setup (date/time output format, PHP version, PW version)? Normally, DatetimeAdvanced should behave just like a regular Datetime field in that regard since it too delegates the formatting stuff to the WireDateTime class, but I might of course have missed some special cases.

I actually came to that conclusion too. The latest release outputs an error message but doesn't throw an exception anymore. There are also instructions on the module config page how to set the correct offset through dbInitCommand in site/config.php so the global timezone in the MySQL server doesn't have to match that in PHP. I'm going to look into that one.

A little self promotion: I just added "date" and "time" subfields to my DatetimeAdvanced replacement for PW's core Datetime field. That lets you search like this: $today = date('y-m-d'); $result = $users->find("birth_date.date=$today"); Also works for in-memory (i.e. PageArray) searches.

Which PW version is that? I tested with the latest dev (3.0.117) and there the values in non-editable languages are shown but not saved (here my user only has page-edit-lang-de, not default or fr):

It's in the selectors docs (admittedly, in the fine print at the bottom of the relevant section):

Because that is how browsers render the del tag. Most (all?) display the contents within del tags like this and the contents of insert tags underlined. IMHO, using the del tag for that typewriter animation script is a poor choice since DEL is a very semantic element. You could work around this by following @horst's suggestions or switch to a different typewriter script that lets you specify your target element dynamically (through a class or id).

It should be even more straight forward: <p><?= $page->one_liner_group->getRandom()->one_liner ?></p> The value of a repeater field is a RepeaterPageArray, which is just a slightly extended PageArray. Edit: @Soma beat me by a few seconds ?

Have you deleted the cache files (site/assets/cache)?

Since the only line with property access is $element = $pages->find("template=clef, langue=$langue, limit=1, sort=-id")->first()->title; it seems that your selector returns no results, so the call to first() returns null and accessing the title leads to the error. Your contributor account may not have permissions on the template or the pages in question may be hidden or unpublished. Depending on the exact scenario, an additional selector is probably necessary (see the link for details).

The error is caused by the code you entered in the field settings. The eval line above just executes the configured code. So if you show us that code, it might be possible to pinpoint the exact issue.

There is already an open issue about this with a workaround.

You can do that using the multi-instance feature of ProcessWire 3. Have a look here.

Take a look at the raw http response body in your browser's developer console. My guess is that some kind of error/warning output from PHP (perhaps a configuration conflict in php.ini or a PHP version issue) performs some early output and thus prevents sessions and login from working. But the raw response should contain some kind of hint about it.

Status update: Release 0.1.3 I finally managed to implement hiding libraries from the page tree as requested in the issue tracker. This can be enabled in the module configuration and optionally extended to superuser. Deletion of libraries is now possible through the Media admin page.

Sorry, I missed this question. I hope this has meanwhile been solved. This looks more like a generic ProcessWire issue, since the upload uses core functionality and the symptoms sound familiar from regular image upload (memory issues or PHP limits).