BitPoet

I think that could be the problem. The redirect for the 404 page comes back without a value in the location header. It might be as easy as checking whether the current page id equals $config->http404PageID to decide whether to redirect or not.

I've done both so far. Since we use PW for our corporate intranet, there are a number of additional databases we pull data from, which is quite straight forward (just an include that instantiates a new WireDatabasePDO and wire()s it). We have a search interface to our test report database where all the data for on-site test runs of our machines are stored, pull in infos about the processing state of lab samples and display an ajax loading tree of standard parts lists for the project engineers from the ERP. Other DBs have been converted to PW pages, like e.g. the archive for the old support ticket system. We even have a mix at some places. For our sales department, we pull the contact information for our worldwide offices from the ERP, create pages if they don't exist yet, and the department augments these pages with additional infos like contractual details that the ERP can't store without climbing through major hoops. We have a semi-live attendance list (the most visitied page by far) filled with data combined from PW's user list (synchronized from Active Directory), attendance status from the time accounting software and person info like the building/room number from the ERP, with the HTML output being generated every five minutes by a background job to ease server load a bit. We have some additional, non-PW tables in the PW database for speeding up things, like caching the listings of large directories with parts drawings, and even wrote our own CKEditor plugins to easily embed links or image tags for these files. You could say PW runs as a big "spider web" that connects all the apps in our company, with data being pulled in wherever necessary. There are a few apps where we thought about storing the content in PW but decided against it due to the sheer amount of data and the performance impact PW's normalization would bring. Right now we're at around 25k pages and a little over 100 fields in 50 templates. We use the UserGroups module and template settings to limit backend access to individual templates and keep the list of available templates short for our editors (~60 editors who never see more than 6 templates in their selection list). Our intranet was built on a different CMS in 2006 and migrated to PW a few years ago, and the possibilities we gained were simply astonishing. It's always fun to have a sales rep for one of the intranet platform solutions on site and, after listing to their spiel about the great features they offer, show them what we have and ask innocently, "How much work would it be to implement all of this?" ?

@Manuel, could you try commenting out the setTrackChanges method in core/Wire.php and replacing it with the following code? protected static $resetTrackChangesItems = array(); public function resetTrackChanges($trackChanges = true) { $isRoot = count(self::$resetTrackChangesItems) == 0; self::$resetTrackChangesItems[$this->id] = true; parent::resetTrackChanges($trackChanges); foreach($this->data as $key => $value) { if(is_object($value) && $value instanceof Wire && $value !== $this) { if($value instanceof Page && isset(self::$resetTrackChangesItems[$value->id])) continue; $value->resetTrackChanges($trackChanges); } } if($isRoot) self::$resetTrackChangesItems = array(); return $this; }

Wouldn't that be fixed too with the correction in the linked issue? The cited error (Wire.php line 1069) points to setTrackChanges.

Here's a way to find all self-referencing page fields. Open your MySQL interface (MySQL Workbench, phpMyAdmin, adminer, whatever...) and execute the following query: SET @oldgcmaxlen = @@group_concat_max_len; SET SESSION group_concat_max_len = 32768; SELECT GROUP_CONCAT(querystring SEPARATOR 'UNION\n') as sqlstring FROM ( SELECT 1 as something, CONCAT( 'SELECT x.pages_id as id, y.name, z.data as title, \'', a.name, '\' as fieldname\n', 'FROM field_', a.name, ' x\n', 'JOIN pages y ON y.id = x.pages_id JOIN field_title z ON z.pages_id = x.pages_id WHERE x.pages_id = x.data\n' ) as querystring FROM fields a WHERE a.type = 'FieldtypePage' ) as inmemtbl GROUP BY something ; SET SESSION group_concat_max_len = @oldgcmaxlen; The result will be a UNION query that checks all your page fields for direct recursions. Here's an example: SELECT x.pages_id as id, y.name, z.data as title, 'permissions' as fieldname FROM field_permissions x JOIN pages y ON y.id = x.pages_id JOIN field_title z ON z.pages_id = x.pages_id WHERE x.pages_id = x.data UNION SELECT x.pages_id as id, y.name, z.data as title, 'roles' as fieldname FROM field_roles x JOIN pages y ON y.id = x.pages_id JOIN field_title z ON z.pages_id = x.pages_id WHERE x.pages_id = x.data UNION SELECT x.pages_id as id, y.name, z.data as title, 'language' as fieldname FROM field_language x JOIN pages y ON y.id = x.pages_id JOIN field_title z ON z.pages_id = x.pages_id WHERE x.pages_id = x.data UNION SELECT x.pages_id as id, y.name, z.data as title, 'pagesel' as fieldname FROM field_pagesel x JOIN pages y ON y.id = x.pages_id JOIN field_title z ON z.pages_id = x.pages_id WHERE x.pages_id = x.data Copy that query into the SQL editor and execute it. If there are any recursions, you will see them listed with the page id, page name, page title and field name.

Maybe you could get some inspiration there from (or even improve on) my JsonNativeField module since MySQL supports searching inside JSON data.

Have you checked in the browser's developer console if there are javascript errors or resources that failed to load?

In Template context, is (currently) is, since the only flag currently defined for templates is the system flag. But @LostKobrakai is correct that iterating $templates isn't really a hardship (and likely faster anyway since there are no selectors parse).

ProcessWire doesn't like module names that have an uppercase letter at the second position, so switching that to lowercase should fix it. Just change CCBillIntegration to CcBillIntegration.

You're welcome. You can set the useLanguages flag on the CKEditor field to get multi language support. $message->useLanguages = true; The only thing you need to aware of is that, as far as I know, there is no fallback to the default language's value if the value in the current language is empty.

The hooks in that list look good to me. A bit of a shot in the dark, but you might try and disable frontend editing in case it is enabled and see if that changes anything.

Just a thought: could there be a before hook on Page::render (perhaps from a 3rd party module) that replaces the original function and prevents after hooks from running? You can see all active hooks with trace with that little snippet: $allHooks = $hooks->getHooks($page, 'render'); bd($allHooks); Make sure to visit a page on the frontend, otherwise ProcessPageRender won't be invoked and Page::render won't even exist (at least that's the case here when testing on 3.0.96.

Just use InputfieldCKEditor directly instead of InputfieldTextarea. You're talking about direct application of Inputfields here. The inputfieldClass needs to be set if you are attaching a field (a FieldtypeTextarea, not InputfieldTextarea) to a template for use in pages.

No reason to worry there. rdbms.strato.de is big load balancing server that hands off the connections to other computers in the store.d0m.de domain. The error says that the individual backend server doesn't respond. That might e.g. be due to a high load there or a bad timing when a switch over to a different server occurs, so Strato support are the only ones who can shed some light on the real cause.

And don't forget to exclude/empty the site/assets/cache directory.

Any chance that it could be a file system permissions issue on the production server in the site/assets/files path?

@Robin S: since all good things take a while, I have committed a tentative fix for the "default to today" issue into the dev branch. Perhaps you could give it a spin and let me know if this works for you.

Out of necessity, I wrote a little module that ties into UserGroups and allows admins to limit the available templates for new pages based on groups. The module is still very fresh but already in production use in our corporate intranet. If there's interest, I'd be happy to have it integrated into / shipped with the UserGroups module itself. https://github.com/BitPoet/TemplateGroups The settings are stored in their own database table (template_groups).

That's currently the way it is implemented. If there's no limit given, then PW ignores the offset (for the curios, it's implemented in PageFinder::getQueryStartLimit). It makes sense from a database point of view since MySQL's LIMIT keyword always needs a row count. So your approach is the correct one. You could perhaps use a reasonably high number (like MySQL's maximum unsigned integer, 18446744073709551615) for your limit. If you don't want to have to remember the value, just put it intosite/config.php like "$config->maxDbLimit = 18446744073709551615;" and then use "limit={$config->maxDbLimit}" in your selector.

Have you tried sorting by -image.count?

Using .htaccess is efficient. You could, in theory, handle (nearly) everything in PHP, but this would add serious overhead, both memory and speed wise. Others have adapted the rules for NGINX, a few like me use IIS with URL Rewrite to power PW, but in all cases, it makes sense to filter and rewrite requests in the web server itself. The topic of supporting more platforms than just Apache out of the box has been brought up a few times already here in the forums. Ryan himself is not opposed to it, but he lacks the time to develop and test the rule sets, and he is of course wary of including anything that hasn't been well tested or that might end up without active support (any changes he makes for .htaccess need to be quickly adapted for other platforms). So I guess it would need a team of knowledgeable volunteers who develop the rules, adapt the installer script, test everything well and provide quick support before he considers integration into the PW project.

Perhaps you can use TracyDebugger and output (bd) whatever you pass to isChanged in your hook?

@pout: even the regular WireMail class shouldn't cause such problems, so it would be good if we could narrow the cause down. Could you check if the issue is still there if you add the following line after the one @adrian linked to: $mail->set("newline", "\n");

This looks okay. You just need to get the correct image from the page. For performance reasons, I'd build an intermediate array that groups the images by page, as you have to load each page into memory to retrieve the image. This way, you can uncache the page after you have rebuilt all its variations. Untested: $query = $this->database->prepare('SELECT name FROM FIELDS WHERE TYPE = "FieldtypeImage"'); $query->execute(); $results = $query->fetchAll(); $pageimgdata = []; foreach ($results as $row) { $query = $this->database->prepare('SELECT * FROM FIELD_'.$row[0]); $query->execute(); $images = $query->fetchAll(); foreach($images as $image){ $pageid = $images["pages_id"]; $filename = $images["data"]; if(! isset($pageimgdata[$pageid])) $pageimgdata[$pageid] = []; $pageimgdata[$pageid][] = $filename; } } foreach($pageimgdata as $pageid => $filename) { $p = $this->pages->get($pageid); $PFM = new PagefilesManager($p); foreach($data as $entry) { $img = $PFM->getFile($filename); if($img) $img->removeVariations(); } $PFM = null; if($p != $this->page) $this->pages->uncache($p); // To clear up memory early in case there are a lot of pages }

Yes, it iterates the page's assets directory, checks every file if it is a variation of the current image and, if yes, recreates it with the constraints encoded in the variation's filename.