Soma

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...

Did you even look in de documentation? http://processwire.com/api/user-access/

Would be nice to know where they come from. There shouldn't be any. But if you use thumbnail module they don't get deleted when deleting image. Well you can't. You may loop all pages an image fields then get an array of all along with all variations. Then delete all images not in this array. Or just delete all except the original as the variations will get created again anyway at some point.

Just created a simple TinyMCE plugin to work around a issue with TinyMCE and using div's (inserted via templates). I know (and many others) of this limitation since a long time, when using templates in TinyMCE and you have a single div you can't add content after it anymore as there's no element that can be focused. There's no real easy solution to this. As I'm also sometimes using (not often, but will in my current project) templates I just created a simple TinyMCE plugin to add a button where if you click it, it will add a paragraph at the end of the content. -> <p>Text ...</p> Here you go: https://github.com/somatonic/addcontent You can add this plugin to PW TinyMCE: create a new folder in /site/tinymce create new folder in /site/tinymce/plugins add this plugin folder into it. The folder should be called "addcontent" now in the PW admin in the TinyMCE configuration settings of your field you can add custom plugins via the text field "Third-party plugin" at the bottom. add this to the text on a new line: addcontent: /site/tinymce/plugins/addcontent add the button to one of the theme_advanced_buttons "...,addcontent" done You should now have a new button in your toolbar, click it to add a new paragraph to the end of the content. I couldn't think of a better name. "addcontent" maybe someone has an better name?

I mean ugly in terms of rewriting all modules and code to use another lightbox plugin. They simply will be broken....

Just created a little helper module http://processwire.com/talk/topic/4432-page-list-show-page-id/

Page List Show Page IdModule prepends page ID in the page list tree labels. Only visible for superusers. https://github.com/somatonic/PageListShowPageId And soon on modules repository http://modules.processwire.com/modules/page-list-show-page-id/ You could also show the page ID or any other field using the template advanced setting for the page tree label. But maybe this is just easier as it doesn't matter what template/pages.

The saving of the status[LangID] is now working with your fix for user, permissions, roles pages. But I'm having issue to solve the problem when saving/creating a new page in front-end on a alternative language. The user language set by language page names module is lost and reset to default after saving. I was getting strange errors when trying: 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) #0 [internal function]: Fieldtype->___savePageField(Object(Page), Object(Field)) #1 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Wire.php(359): call_user_func_array(Array, Array) #2 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Wire.php(317): Wire->runHooks('savePageField', Array) #3 [internal function]: Wire->__call('savePageField', Array) #4 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Pages.php(718): FieldtypePageTitleLanguage->savePageField(Object(Page), Object(Field)) #5 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Pages.php(605): Pages->savePageFinish(Object(Page), true, Array) #6 [internal function]: Pages->___save(Object(Page)) #7 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/core/Wire.php(359): call_user_func_array(Array, Array) #8 /Applications/XAMPP/xamppfiles/htdocs/pw2-dev/wire/cor Which means the page has no id at some point in save routine. The fieldtype throws this error. A few hours later I found by outputting "page field" infos in various methods of the pages save process I tracked it down to being an issue with repeater field. As soon as I remove repeater it works! And the language is correct again after saving. Also it is a little strange what is happening, even after the hook saved() get's called the page isn't really saved yet, as the repeater also has pages that needs to get saved. So a hook on Pages::saved() is called multiple times. As soon after saving the repeater page(s) (FieldtypeRepeater::savePageField()) it calls the parent savePageField() again and there it somehow fails as suddenly the page id is zero! Looks like this: Pages::savePageFinish(): pid:2257 -> hide_de Fieldtype::savePageField() : pid:2257 -> field : hide_de Pages::savePageFinish(): pid:2257 -> state Fieldtype::savePageField() : pid:2257 -> field : state Pages::savePageFinish(): pid:2257 -> myrepeater FieldtypeRepeater::savePageField() : 2257 -> myrepeater Pages::savePageFinish(): pid:2258 -> title Fieldtype::savePageField() : pid:2258 -> field : title Pages::savePageFinish(): pid:2258 -> process Fieldtype::savePageField() : pid:2258 -> field : process Fieldtype::savePageField() : pid:2257 -> field : myrepeater Pages::savePageFinish(): pid:0 -> title Fieldtype::savePageField() : pid:0 -> field : title page : 0 (error) no page id!

Or you can hover over the edit link to see id.