BitPoet

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).

Why call $pages->find at all? foreach($page->fieldname as $child) { should do the job.

The reason (at least how I read ryan's responses to questions about the options field type) is that more often than not, a page field is the better (i.e. more flexible and extensible) solution when you want to allow the user to make a choice. Having the field type installed by default would probably tempt users to start using it right away without learning to appreciate the power and ease of page fields. There are a few use cases for the options field type, like simple dropdowns in frontend forms (that's where I use them). But a page reference field supports drag&drop reordering of options for editors, it's easy to give the template for the selectable pages a PHP template too to list all pages with that option, you can publish and unpublish "options" without deleting/adding them, regular editors can do that (and add/remove options) without a need to mess with the field's configuration, and the API side is much more intuitive and flexible too...

@jmartsch: are these admin pages regular pages open in ProcessPageEdit, custom Process modules or pages added through AdminCustomFiles? In each of these cases, the answers might be a bit different.