Soma

Ok I tested again with another install. When viewing page on default language (/de/about/), and in template create or edit a page (always with API): 1. creating page works fine, language is same before and after 2. editing the page and modifying the title of each language, I get the famous error 3. when removing repeater from template, it works, no error When viewing page on alternative language (/en/about/), and in template create or edit a page 1. creating fails, error 2. editing fails, error 3. when removing repeater, it works fine Hope this help you reproduce

Hmm. Just from API side (see code examples I posted) when editing or creating a page with repeater. Repeater isn't populated (see my code) and the repeater has title language field. The repeater has 3 items ready. I think I provided all informations in above posts and I don't know what else I can give without repeating. :/ No, I don't know if other factors than removing repeater change behaviour. As soon as I remove repeater it works fine, add it back and it throws error.

Me again. I glimpsed at what you already done with that "wrapper". I now got it working for TinyMCE links plugin. So it will create localized urls when selecting from the page tree. I had to modify a couple files to add a langID option to ProcessPageList and ProcessPageEditLink. Should I just make a pull request with those changes so you can look at and test? Edit: Pull Request done https://github.com/ryancramerdesign/ProcessWire/pull/241

Ryan, this is a very important feature to complete the language support. I'm currently working on a multilanguage project that will maybe need to have links localized in TinyMCE. Can I somehow help with this? I'm not sure what you already have done, but will take a look. Any pointer would be greatly appreciated.

Yeah of course you could just output scripts along with the "form" output. Thanks apeisa for throwing that in. That being said, there's not many modules that generate markup apart from this module and the case where a module needs to output code in the template is rare but of course possible (using render hook). I think if you use this shop module you anyway need to create templates and template code to make it work and adding a line or more to account for scripts is not that bad at all. PW gives you flexibility here as it doesn't dictate how you need to use it. In case of the shop module it is also possible to create you own markup for all the cart, checkout etc and only use the low level functions provided by the modules.

Usually this is a good and simple method: In a autoload module you hook into the processInput of InputfieldTextarea. public function init(){ $this->addHookAfter("InputfieldTextarea::processInput", $this, "validateText"); } public function validateText($event){ $field = $event->object; if($field->name == "body"){ $page = $this->modules->ProcessPageEdit->getPage(); $oldValue = $page->get("$field->name"); $newValue = $field->value; echo "old value: " . $oldValue; echo "new value: " . $newValue; if($newValue !== $oldValue){ $field->value = $oldValue; $field->error("Go away!"); } } } For a error message you simply add error("text") to the field. It will get showed after saving. What this examples also shows nicely is how to get the old value and new value. The code may slightly varies for different type of fields but the principle is always the same. There's also a method to hook into Pages::saveReady() but I'm not sure what the advanced really are atm.

At least he hasx a avatar.

vxda glad you figured it out. It's always good to check if there's images, you could also use count(), and maybe also not output the image if there's no image. So you could also do ... $out .= "<li><div><a href='{$newsitem->url}'>"; if ($newsitem->images->count()) { $out .= "<img src='{$newsitem->images->first->size(313,177)->url}'/>"; } $out .= "{$newsitem->title}"; ...

.. had to run .. so if we go from the default PW site setup with head.inc and foot.inc in your sc-checkout.php you would do it like this: $checkout = $modules->ShoppingCheckout->renderCheckout(); include("./head.inc"); echo $checkout; include("./foot.inc"); If you want to add the scripts getting loaded in header in head.inc If you have your scripts before </body> in foot.inc you can also do include("./head.inc"); echo $modules->ShoppingCheckout->renderCheckout(); include("./foot.inc");

Since it wouldn't be autoload, It will only get loaded after when you call checkout render in your template. So as I mentioned it would have to be after the echo $modules->ShoppingCheckout->renderCheckout();. If you have the script output before it won't work. It depends how you use templates, and the order is important.

Ah sorry for the typo!

try $input->urlSegmentsStr $input->urlSegmentStr #280 WireInput.php

Yeah I understand your point and I provided the best/correct solution, so you could make your payment module autoload and add hooks. So should be no big deal. This isn't the official shop module thread btw. Users/admins don't have access to install modules only superusers. So this is usually the site builder that is concerned about installing modules. Adding a line to the templates and be done with it when setting it up makes it a lot more modular at the end. With doing this to add script via a render hook as you said it's a "hack" that has several drawbacks. - render hook might get called 2 times, if one decided to use a $page->render() mvc approach to render pages, so the scripts will get added 2 times - as you said, scalability, it may not important with 1 module on 1 page but you get it - if you have multiple payment modules doing what you do, they will all add scripts, so you also have to check for what payment module is selected. I agree it's a little different topic, but the best way is what I showed using $config->scripts, $config->styles. Ultimately it's also what PW admin is doing. Through a render hook might be ok in cases but I wouldn't settle on that as a best practice.

What you mean by "you have to integrate that code line in the template header" ? Why is this bad? (You can also use it for other cases where you need to add scripts.)

But the autoload feature makes it load on every request. If you're happy with that So you'd have to restrict it to the particular page, parse and add the html to the page. Here's a better approach: Load the script to $config->scripts->add("url/to/script.js"); public function init() { $this->config->scripts->add($this->config->urls->PaymentExample . "script.js"); } and adding this to where the scripts should be loaded in the template file: <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> after the checkout module render call of course. This is also used by the admin to add and load scripts and css from modules.

Thanks hdesigns, but I think this could be solved differently. First off I'm not sure why you need a Page::render hook in the payment module, since as you said you'll need to make it autoload. So it will get loaded on every request, so it doesn't really make sense to add the hook in the payment module, since it could also be added through a simple WireData module. $this->modules isn't there yet defined in the __construct, so to solve this we could move the config stuff into the init() method in the abstract class, as in the init all those API vars are ready. Only thing what I found when quickly testing this, is that the title text $this->title = $this->_("Payment Example"); needs then to be moved to the __construct of the payment module, so checkout module will get it.

It's not like that PW need to step through a forest to look for tree with a number on it. It has google earth showing it with a bubble "here I am".

Also maybe worth noting is that if you specify multiple id's... $pages->get(" id=1001|1004|2003|3233,template=book,title=Mytitle"); This will be again different since it's not explicit anymore, and additional selectors will again be validated.

Both the same and since you specify a id explicit, it will just get that page and the template wouldn't be required. But actually there's a difference in it: $pages->get($pageID); Will get the page even if unpublished, in trash, hidden or user would have no access! It isn't doing a real "find" and it's much like getting a row from DB no matter what. It's like a shortcut PW is doing in this case not doing a usual page finder search. $pages->get("template=book,id=$pageID"); This will convert the previous into a "page finder search" much like when using a find("template=book, title=Mytitle"), thus behave different. It will not return a page if unpublished or hidden or in trash or the user has no access. EDIT: In fact in the last one, it will even get the page even if the template isn't correct! So the id=id is the key here. Any selector will get ignored. So doesn't really make sense to add selector if you got the ID. Page ID is one of the things that's unique an always the same untill you delete it.

It is possible and the solution is in the formbuilder forum. Ryan should give you access.

Along with the module I guess. A folder ln8i or what is it called.

And have lots of scrollbars? No pleas not!

Thanks, but I got my own (Oh dear)

Also recognized that this field doesn't work with the FormSaveReminder listening to form changes. Could you implement a call to make the form changed as soon as a change happens to input you done via script? I for example had to add this to color picker for FSR to work: $(this).parent().find('input').val($(this).data('default')).trigger('change'); It's kinda stupid that every inputfield that has special js like updating of fields or hidden fields needs to have this trigger change on input implemented or FSR can't do its work, otherwise the module is kinda pointless What you think? Do I now need to hunt down every field/inputtype module that will be created and ask to implement this? Should it be a mandatory implementation we advise? So this sort of save reminder is even possible and reliable.

I can't get this to work. Displaying and selecting works fine but as soon as I save I get Page 1001 is not valid for select_page I specified the template via a custom selector. As soon as I select a template from the option dropdown the error is gone, but the selected options aren't saved. They aren't showing on the left side but also missing on the right. I'm using latest PW dev. This was switching from a previous single page select to this new transfer inputfield. After saving and moving options multiple times it seems to work again.