BitPoet

I'm a bit at a loss where to put my hooks. My requirement is to have a checkbox in the page (already there) that tells my module to pull fields (i.e. body, headline etc., but possibly others too in the near future) from the default language, no matter if there's a value set in the current language, and apply some replacement before rendering (think HannaCode-like, though with a whole dictionary database for technical terms behind it). Now, I'm unsure where to hook. I've looked through the LanguageSupport modules and tried to spy in HannaCode, but I've not been able to wrap my head around all the getLanguage..., getFormatted... and whatnot hookable methods involved. Attempts at overriding LanguageSupportFIelds::hookFieldtypeFormatValue and extending its logic somehow ended up with an endless recursion. If anybody could give me a few pointers (or method names) I should look for, this would be great.

Sorry, just copy&pasted from my code, so I used {} instead of php tags as the snippet I copied from was within a PHP echo(). <?php echo $config->urls->templates; ?>bbp/img/logo.jpg should always point at the same logo at "[YOUR PW DIRECTORY]/site/templates/bbp/img/logo.jpg". Basically, it shouldn't matter if you're using $config->urls->root or $config->urls->templates, the latter is just a little shorter and more "speaking". I'm not completely following what you mean with "on the page itself while inserted in the article". Can you give an example?

The URL to the template directory is stored in $config: <img src="{$config->urls->templates}bbp/img/logo.jpg" alt="Home" width="282" height="78" /> Equally, using $config->urls->root as the base for any local resources residing outside the templates directory makes them path-agnostic as well.

It does (with a little tweaking). I've basically set it up so I have a php class with all the neccessary functionality and created both a graphical interface in a backend page to do individual tests (simple source+target selection and optionally go one level deeper) and a cli wrapper for bulk migration and creating dumps for recalcitrant pages. The biggest problem will be tweaking the HTML contents and contained links so they don't get shredded in CKEditor. Some were created with older versions of TinyMCE (with some home-brewed tweaks that I'd now avoid like the plague), some bulk imported from centuries old pages created in Netscape Navigator and Frontpage as far back as the middle of the nineties, so it's quite a mess.

I'm migrating our corporate Intranet from Contenido to PW. ~8500 pages, 2 languages, 400+ users, about 20 modules and templates. I'm a little more than halfway there right now, most modules are working as planned and the first migration tests look promising, though I'm pretty sure a few headaches will be popping up when I start with bulk imports (though those won't be PW's fault...).

Or, going completely overboard using recursion, only loading pages to the requested depth: function getAncestors($pg, $level) { $retPages = (new PageArray())->add($pg); if( $level > 0 ) { foreach( $pg->children As $child ) $retPages->add(getAncestors($child, $level - 1)); } return $retPages; }

I did my first fork and pull request with git - which turned out to be far less mysterious than anticipated - and Ryan already accepted my fix. Thanks!

Here's my first serious attempt at a PW module. I have the need that pages shouldn't be "published" in all languages at once, so I've put together a PageLangPublish module. It adds both buttons for publishing/unpublishing of each language to the page tree and status icons (from image fields added to each page in admin/languages) next to the page title in the tree. You can find the module at github under https://github.com/BitPoet/PageLangPublish I've probably done a lot of things quite awkwardly (even incorrectly) there, so I'd be grateful for any pointers and ideas. The module also adds a hookable isLanguageViewable method to the Page class. Usage example: $topnav = array(); foreach($homepage->children as $item) { if( $item->isLanguageViewable($user->language) ) { $topnav[] = "<a class='topnav' href='{$item->url}'>{$item->title}</a>"; } } echo implode(" | ", $topnav); Here's a screenshot:

Thank you for the pointer, adrian. I've commented on the issue.

Not sure if this is by design - or if I'm perhaps missing the obvious. I'm just getting my feet wet with pw (2.5.3) and have created a partial sitemap template (nothing fancy, just recursing through a partial tree). When I added a page field to my sitemap template, selected a page and tried to save, I got a memory limit exceeded error. The problem appeared only when the page picked in the page field was the same as the one being edited. public function resetTrackChanges($trackChanges = true) { parent::resetTrackChanges($trackChanges); foreach($this->data as $key => $value) { if(is_object($value) && $value instanceof Wire) $value->resetTrackChanges($trackChanges); } return $this; } Looking at this method, I guess it's easy to see that this will run in an endless loop if one of the properties of $page is once again $page. As a quick fix, this could be cured by comparing $this and $value in the conditional, but there'd still be a possibility of building circular patterns that have the same problem. Not sure how to go about that. Edit: Of course, InputfieldPage prevents me from even assigning the same page here at all (my fault). Still, the check in Inputfieldpage::isValidPage appears to happen too late.