Soma

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.

Thanks for mention it! Yes yes this is the other strange thing I noticed as well when using pre element. Now just thinking about it we may need a prepend and an append button...

overflow: hidden, will hide any content overlapping container, z-index: 999 doesn't solve this. I had various discussion about this particular issue with no float clearing happening on container in PW since a long time. Recently we had more discussion going due to others mentioning this. Looks like Ryan now implemented the wrong solution, although I mentioned it in a conversation. But I still have a hard time explaining Ryan the issue as he doesn't seem to know or recognize it. This again is a clear case where adding overflow hidden is bad.

@hdesigns: See my monolog here: https://github.com/apeisa/Shop-for-ProcessWire/issues/2 And this: https://github.com/apeisa/Shop-for-ProcessWire/pull/4 I'm not sure if apeisa ever receives messages from github...

I can't reproduce this using latest dev. When deleting a page with API, the repeater also get deleted from that page. Like $pages->delete($pages->get(2300), true);

Many years now ago since I last used Firefox and Firebug. I don't use FF at all anymore (just to make sure website works), since they messed up so bad I couldn't work with it anymore (slow, buggish, until today). Chrome Dev Tools is far superior to Firebug, I think even the recent new Dev Tools native in FF is better than Firebug, but can't really say.

This would work: $out = "<p class='summary'>{$tp->summary}</p> <hr/>"; $out = rtrim($out , "<hr/>" ); If you remove the space in the "<hr />" and the space before the " <hr/>" in the trim it works. Keep in mind, rtrim removes chars and not tags/strings, so what you specify in the second argument is actually a chars list and not a string to be removed. Also if doing this way, a space after </p> is required to make it work also. Better stick with other methods in this case.

No, this does only solve the language issue after saving when not having any repeaters on the page edited/created. Error below still exists and even without any changes to page names module. Error: Exception: Unable to save to 'field_title' for page that doesn't exist in pages table (in /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Fieldtype.php line 506)

In my tests (although a little long session with forth and back) it was not working even without any modification to current page names module. The problem really is the repeater here. Without any repeater it works. But I tried and came of with a much simpler solution to yours, but not sure it would be really the way. You were using a temp property set to the page before saving and reading it after which I think is strange as I would think this value would may introduce other effects? Also you used $user instead of $this->user, however I removed you code and commented. Here's the current version I have. LanguageSupportPageNames.module And I tested in template with something like this: echo "user lang before: $user->language<br/>"; /* to create a page */ $p = new Page(); $p->template = "basic-page"; $p->parent = "/"; $p->of(false); /* to edit a page */ // $p = $pages->get(2179); // echo "page title: $p->title<br/>"; $p->of(false); $n = rand(1,100); foreach($languages as $lang) { // $id = $lang->isDefault() ? '' : $lang->id; // $p->set("status$id",1); $user->language = $lang; $p->set("title", "{$n}_titleofpage_lang_{$lang->id}"); } $pages->save($p); echo "page saved '$p->name'<br/>"; echo "user lang after: $user->language<br/>";

800 fields!? You're crazy This of course would be a important factor. I think it would all work but you'll need a strong server to handle that much fields. Even though then it may can handle it it would be still quite a load on server. So the question would be why 800 fields (crazy) and a template with 400 fields (crazy) is a -bit- overkill. I'm not sure how it comes you need so many fields on one page. Unfortunately I don't see much that could be done in the list fields admin that renders all fields as a list, since now it used a lot of filtering and grouping by labels it can't be easily paginated or something. Only thing I see would be to create custom fields list admin that is limit to 50 fields, or use a search (admin hotkeys can do this too) to get to a field. I'm also thinking if it wouldn't be possible to simplify this. As diogo mentioned you could maybe serialize the data some. After all this sound a lot like a data heavy application (really heavy) that maybe too much to go the PW way of creating all and every field as a field and attach it to a template. This sounds more like a custom application that could use a custom database or tables. What I would consider is, as you said, to build some custom tables for the data and use SQL queries. Or what you could try is creating some custom simple fieldtypes that store groups of data fields to a table at the end. Like a field stores prename,lastname,address,tel etc. You'd then have less fields and still could use the API and selectors. If you need help we are here to guide you. What I also thought is (but don't see the full context) why add 400 fields to a template and not split it up to many templates and use hierarchy in the tree with child pages to store data. But then still you'd have a lot of fields. Some of the larger sites I have +-100 fields and I think it's already quite a lot (some are alternative fields _de, _fr, _en etc). So if you could let us know more details of how it comes to you creating 800 fields it may help to understand and find alternatives.

What you think how much time I have spent with try and error and so any coder living except maybe Woz. It's part of the business and if one is not willing to try he get nowhere. When I make designs it's practically the same.

Maybe good to read the documentation http://php.net/manual/en/language.types.string.php

I like curly women.

Best I could find is where you asked the same q and got a answer by Ryan with example steps. http://processwire.com/talk/topic/3346-setting-up-manager-role/

My bad...