BitPoet

Is opcache enabled in PHP? If it is, this could be a name collision problem. You can check by calling ini_set('opcache.enable', false) in site/config.php and see if the problem still occurs. If that helps, there are a number of configuration options to look at, most importantly opcache.use_cwd, opcache.validate_timestamps, opcache.revalidate_paths and opcache.enable_file_override, all documented here. There's an interesting article at sitepoint that lists a few tools for working with opcache if it really is the culprit.

The name (array key) you set in your getExtraActions hook needs to match what is passed as $action in the processAction hook. You're using "delete" in one place and "wipe" in the other.

Or, even better since it avoids a roundtrip through the database, would be Pages::cloneReady, which is called after the page is copied in memory and before it is saved to the database. Usage is the same, sans the call to $newpage->save(). I'm using Pages::cloned in my module because I need the ID of the new page which is only available after it has been saved.

Since we're talking modules, one needs to use a relative or dynamically assembled path, and make sure that it doesn't break when FileCompiler comes into play. Thus, if the class is only to be used by the module itself or by code that explicitely references the module, adding it to the module's file is IMHO the most reliable approach.

Looks like all you're missing is InputfieldPassword.css.

It's already like this in the installer sql script, so it shouldn't be much trouble to change the property for all pages with parent 1. I wonder, though, in which circumstances this would be an issue, since the sort order is still correct. So if anything, I'd regard this as a feature request and not a bug. Just my 2 cents.

PHP's memory limit is an ini setting just like the maximum script execution and set by your hoster. Perhaps you can try with a truly small image and see if this works, just to make sure it is really a case of the script taking too long vs. the script crashing without the CGI handler realising it. If this works, you could try and go up in steps to get a feel where the size limit is. I'm not sure what's the best way to get some sensible debugging information about that, perhaps someone more familiar with the image modules can chime in here.

Issue #43 filed at GitHub and pull request submitted.

That's strange, and it looks like there's something else (mailserver?) adding the quoted-printable encoding. But I noticed that I haven't based the code above on the most recent version of WireMail, so I'll run some tests myself and try to propose a solution that also takes cases like utf8 characters in names, line wrapping and such into account in an RFC-compatible way.

I can see two issues there: The Content-Transfer-Encoding needs to be 8bit to support raw utf8 characters The subject needs to be encoded using either quoted-printable or base64 (quoted-printable is most common there, as it leaves parts of the subject readable) Changing the affected functions like this in WireMail.php should get things working with umlauts: public function subject($subject) { //$this->mail['subject'] = $this->sanitizeHeader($subject); $this->mail['subject'] = '=?utf-8?Q?'.quoted_printable_encode($this->sanitizeHeader($subject)).'?='; return $this; } public function ___send() { $header = ''; $from = $this->from; if(!strlen($from)) $from = $this->wire('config')->adminEmail; if(!strlen($from)) $from = 'processwire@' . $this->wire('config')->httpHost; $header = "From: " . ($this->fromName ? $this->bundleEmailAndName($from, $this->fromName) : $from); foreach($this->header as $key => $value) $header .= "\r\n$key: $value"; $param = $this->wire('config')->phpMailAdditionalParameters; if(is_null($param)) $param = ''; foreach($this->param as $value) $param .= " $value"; $header = trim($header); $param = trim($param); $body = ''; $text = $this->body; $html = $this->bodyHTML; if($this->bodyHTML) { if(!strlen($text)) $text = strip_tags($html); $boundary = "==Multipart_Boundary_x" . md5(time()) . "x"; $header .= "\r\nMIME-Version: 1.0"; $header .= "\r\nContent-Type: multipart/alternative;\r\n boundary=\"$boundary\""; $body = "This is a multi-part message in MIME format.\r\n\r\n" . "--$boundary\r\n" . "Content-Type: text/plain; charset=\"utf-8\"\r\n" . //"Content-Transfer-Encoding: 7bit\r\n\r\n" . "Content-Transfer-Encoding: 8bit\r\n\r\n" . "$text\r\n\r\n" . "--$boundary\r\n" . "Content-Type: text/html; charset=\"utf-8\"\r\n" . //"Content-Transfer-Encoding: 7bit\r\n\r\n" . "Content-Transfer-Encoding: 8bit\r\n\r\n" . "$html\r\n\r\n" . "--$boundary--\r\n"; } else { $header .= "\r\nContent-Type: text/plain; charset=\"utf-8\""; $body = $text; } $numSent = 0; foreach($this->to as $to) { $toName = $this->mail['toName'][$to]; if($toName) $to = $this->bundleEmailAndName($to, $toName); // bundle to "User Name <user@example.com" if(@mail($to, $this->subject, $body, $header, $param)) $numSent++; } return $numSent; } If the names in From: or To: headers contain umlauts, they also need to be properly encoded. My fix for the subject() function above is a bit crude, as it doesn't care for long lines that should be wrapped. There's also the mb_encode_mimeheader function in PHP which does wrapping but doesn't care for word boundaries and might cause superfluous whitespaces in between words.

Just to close in on the cause: does placing this line in your module's init function help? $this->modules->get('LanguageSupportPageNames');

Errors like this are often caused by too large images. When you request a certain size, both the original image and the resized one (plus some computational overhead) have to be read into the main memory, so it's possible you're hitting PHP's memory limit.

Do you have $config->debug enabled? If yes, does setting it to false change memory consumption? Also, you may try calling gc_collect_cycles() at the end of the loop after uncaching the page, to allow PHP to garbage collect unused objects with circular references.

It does.

Why not hook into Page::viewable and, if the template is documentation, apply your own logic?

Always happy to help For anybody who feels daring and wants to try it, you can find the patched module here until kongondo finds the time to test my changes. Use at your own risk Edit: Link removed since my changes have been merged into the official module. Please keep on walking, there's nothing to see here...

Quick update: it turned out that the problem of blog_files not being added to the template is due to $this->files somehow having become a reserved variable. It holds an instance of WireLog instead of the blog_files field created earlier, though I haven't spotted the part in the core where this happens yet. However, changing $this->files to $this->blogfiles fixed the problem. I'm now going to run some tests. Stay tuned.

@antoiba86: I don't think downgrading is really an option. But I've already got the magnific and markup issues sorted and am working on the issue with the blog_files field, so a 3.0-compatible version is around the corner. @kongondo: as I've got a few sites running on 2.8, I try to stay clear of namespaces anyway

@antoiba86: Welcome to the ProcessWire forums! Are you using ProcessWire 3.x? I'm currently working on making the blog module compatible with the latest PW versions, and I also encountered this error. It is caused by something that goes wrong in the install routine, which fails to assign the blog_files field to its template. I'm working on it and have an idea about its cause, but I haven't tracked it down completely, and there are a few other issues (mainly the switch to jQuery magnific popups) I'm working on as well since a lot has changed under PW's hood. The blog module should work on PW 2.7, though, which is also linked on the download page, so setting up your blog site on 2.7 and upgrading everything once the blog module has been adapted and tested on 3.x (give that a week or two) might be an option.

A few minor optimizations: the "else" block isn't necessary no need to put the "class=\"something\"" into the variable, you just need to store the class name HTML attributes can also use single quotes, which makes assigning them in interpolated strings easier to read you have two identical if/elseif conditionals for the class and for rendering children, so you can set a flag in the first place storing the result of wire('page') in a variable (I used $page) shortens the code $a != $b is (to me) more readable in complex conditional expressions than !($a == $b) Untested: <?php // ... function renderMenu($items) { $page = wire('page'); // if we were given a single Page rather than a group of them, we'll pretend they // gave us a group of them (a group/array of 1) if($items instanceof Page) { $items = array($items); } $str = ''; foreach ($items as $item) { if ($item->showInMenu == true) { $menuText = $item->get('menuLinkTitle|title'); $currentClass = ''; $renderChildren = false; if ($page->id == $item->id) { $currentClass .= "current"; $renderChildren = true; } elseif ($page->parents->has($item) && $item->id != 1) { $currentClass .= "current-parent"; $renderChildren = true; } $str .= "<li><a class='$currentClass' href='$item->url'>$menuText</a>"; if ($page->id != 1 && $renderChildren) { $str .= renderMenu($item->children); } $str .= "</li>"; } } // if output was generated above, wrap it in a <ul> if ($str) { $str = "<ul>$str</ul>"; } return $str; }

I should have a pull request for magnific support and to fix some raw markup issues ready tomorrow evening.

I fail to see anything wrong there. The title tag looks fine to me (in FF, Chrome and Edge). <title>Surf Inn - holiday accommodation Cape St Francis</title> Perhaps just a case of a stale browser cache?

Anybody feeling adventures could use my (still a bit experimental) DatetimeAdvanced field. With that, the code gets a little more concise. The retrieval of the oldest page can be optimized a little with the findOne method when using PW >= 3.0.0: $firstEntry = $pages->findOne("parent_id=1037, sort=date_1"); foreach (range(date("Y"), date("Y", $firstEntry->date_1)) as $year) { $count = $pages->count("parent_id=1037, date_1.year=$year"); if ($count > 0) echo '<li><a href="' . $page->parent->url . $year . '/">' . $year . '(' . $count . ')</a></li>'; }

Are you passing the full URL to the constructor, i.e. something like "http://yourhost/yourpath/"? If yes, is the formatted value of the field still set to "Automatic"?

Is imagefield set to return a single image? This looks like you're accessing the data from a Pagefiles object. In that, case, this should work: echo $site->pages->get(pageid)->imagefield->first()->httpUrl;