BitPoet

See the AdminCustomPages module. It helps you do exactly that.

Run "php -i" from the command line. It will list all installed modules, and even more, it will give you the location of the php.ini file used by the php cli - it's not neccessarily the same as your webserver module uses. So on linux, running php -i | grep php.ini or on windows php -i | findstr php.ini will give you a line reading "Loaded Configuration File => PATH/TO/php.ini". Make sure that this file also loads all required modules. It might also be worth it to make sure that the php executable you start in fact belongs to the same installation as the library loaded into the webserver. With the popularity of bundles like [X|W|L|M]AMP I've often seen the path still pointing to outdated older php installations while the server used a far newer version.

Pass the product to renderAddToCart: echo $modules->get("ShoppingCart")->renderAddToCart($product); The method tries to use the current page as the product page for which to render the button if none is passed as its argument, but since you're calling it from a non-product page without an sc_price field, it doesn't find anything to render.

For users with page-edit permissions, there's also the JSON API in ProcessPageSearch, callable like <?= $config->urls->admin ?>page/search/for?template=basic-page&include=hidden

_getField definitely needs to return $field. Tested by manually adding "return $field;" in line 427. Pull request sent through github. https://github.com/ryancramerdesign/ProcessWire/pull/931

This is because of assignments inside function calls, which should be avoided at all costs, e.g. in line 329 of FormHelper.module (279 is the other one): if (!empty($files = $this->files[$fieldName])) { Strict mode barks on this because assigning to passed variables like this breaks pass-by-reference. Consider these two snippets: $x = 1 byref($x); echo $x . "\n"; function byref(&$val) { $val = 3; } This correctly echoes "3". Now lets do the same and assign $x in the function call: byref($x = 1); echo $x . "\n"; function byref(&$val) { $val = 3; } Now our output is "1", which is of course not what we would have expected after assigning to a variable passed by reference - our assignment has turned the pass-by-reference into a pass-by-value. The original line should be written as: $files = $this->files[$fieldName]; if (!empty($files)) {

Just use $image->name as a reference. If the same image is added twice, a unique name is generated for the second one (just like when you add identically titled pages under the same parent).

Thank you both, Soma and LostKobrakai. Textformatter and getUnformatted in combination were what I was missing! Here's the working code - short and to the point: public function formatValue(Page $page, Field $field, &$value) { if( $page->isMultiLang == 1 ) { if( $this->user->language != 'default' ) { $value = $page->getUnformatted($field->name)->getDefaultValue(); } $value = preg_replace_callback('/\{TR:([^}]+)\}/', array($this, "translate"), $value); } }

Basically, I've got migrated articles in multiple languages. The body text in the default language (German) contains translation tags in the form of "{TR:Teil}: xxx.yyy.zzz - {TR:Gehäuse}". These TR tags need to be read, the text extracted, translated and replaced (or, if accessed in the default language, just the tags stripped) so the page displays "part: xxx.yyy.zzz - housing" for English and "Teil: xxx.yyy.zzz -Gehäuse" for German. There may be a body text in English as well, so relying on the "use text from default language if empty" feature is unfortunately not sufficient.

Huh. My enthusiasm was premature. Unfortunately, this only works if I don't need to modify the text value in the default language. If I try to do the latter, I once again end up in an infinite recursion. I tried to move the default language replacement part into a textformatter, but then the value gets replaced with the original one again. I'm at a loss.

Thank you! That was exactly the place. I had to fiddle a bit because I tried at first with $page->getLanguageValue which again led to an infinite recursion, but this works: public function init() { $this->addHookBefore('FieldtypeText::formatValue', $this, 'hookBeforeFormatValue'); } public function hookBeforeFormatValue($event) { $page = $event->arguments(0); $field = $event->arguments(1); $value = $event->arguments(2); if( $field->name == 'body' && $page->isMultiLang == 1 && ! $this->user->language->isDefault() ) { $lang = $this->user->language; $this->user->language = wire('languages')->get('default'); $value = $page->get($field->name); $this->user->language = $lang; // Pattern replacement part comes here $event->return = $value; $event->replace = true; } } I've thought about making the valid field names configurable in the template definition, but that's probably a bit too steep right now. Thanks again!

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.