Soma

In the Field setting screen of a TinyMCE field you can configure much if not everything. Tab "Input" you see the TinyMCE Advanced Configuration Options. Add "paste" to the plugins string. Add paste_text_sticky: true paste_text_sticky_default: true to the Additional TinyMCE Setting field. If you want to add it globally to al TinyMCE fields you could add following to the default.php in your admin theme. Before closing </head> <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) { InputfieldTinyMCEConfigDefaults.plugins += ",paste"; InputfieldTinyMCEConfigDefaults.paste_text_sticky = true; InputfieldTinyMCEConfigDefaults.paste_text_sticky_default = true; } </script>

I just installed this and after installing I get an error. Error Using $this when not in object context (line 287 of .../site/modules/ServicePages/ServicePages.module) $this is used in a static method, I wonder that this works on your side? Is this php version related?

I somehow adopted to the slash and also used it in codeigniter. It works and is consistent and you just don't need to think about it once you start messing around with it, it can get a burden. I also see it as if it's all a folder and a document at the same time. Consider this: /templates/ same as /templates/index.php And both work in PW. Or is it my local install. Anyway. Edit: yep it's only if urls segments are enabled.

Just use a text field and make the type = password. $field->attr('type','password');

If you would let us know what exactly your doing codewise with you categories and locations it would help finding what's going on. I have tested a little more and I have 800 pages and when going to a page that's on position 800 it has to parse all page 800 to that point, but when prefix id's is enabled it does a good job. Execution times a slightly higher, as it is without the module enabled. And I'm talking about ~0.1 seconds. But it all depends how many heavy code you are performing. SInce I'm not sure in your case if it's the finding pages or generating urls that causing the slowdown, I'm curious to know exactly what your doing in your templates. Not really a solution since I don't know yet what's causing the problem. But with id's enabled it's a lot better optimized as if I would use a index table to get pages quicker. Again I can image it's something different, as I have no problems in my testcase.

How about findRandomDelayed() or findRandomInterval() ?

If I include it in the index.php I also can output log in a modules ready(). It even logs ajax requests on the pagelist tree xhr. Not sure why it's not working for you.

Hmm, I included it in frontend main template at top and works. I include it in PW root index.php on line #184 and it works.

Works fine here. Where nclude it and where? BTW looks like a nice tool, thanks for posting.

Also foreach($parr as $key => $p ) works fine ... Key is not pid.

If($pages->last() === $page)..

IMO it open some inconsistency with the system I don't like. I like the way it is and client should deal with it and it should always be same, that's why PW is so great. I'm personally not keen with having possibility to change the process to different behaviors and inconsistency throughout the system. There a simple approach as we mentioned with template family settings and field template context which is a good thing.

ProcessWire requires to have the title and name field for every page. If you remove the title you need to turn off global setting of the title field and remove it from the template you wish, BUT this will result in every page you create not having a title field. Technically I think it only needs the name field at the least. So this might be not a problem, as you could see "name" field like a filename when you create a file. However you could also 1.) setup a template "persons" and make it only allow children pages of the "person" template. (In the family tab you can select allowed children templates.) 2.) In the person template you click on the "title" field and it will open an dialog editor to edit the field attributes in context to the person template, enter "Name" instead of "Title" in the label field and save. 3.) Then if you ceate a new child page under the page with the "persons" template, it will show the title field labled as "Name".

I remember discovering that admin pages are in the tree... Great times

Edit: Ok, I found that if I open the developer tools in chrome the render bug is appearing. When I close the dev tool it's gone.

I also noticed this recently, but checking now on my local install it's gone. I have updated and am now on 23.0.1271.64. I also think it is more an issue with Browser than Tinymce. So maybe Chrome already fixed the render bug. It appeared suddenly, and since automatic updates you get new updates almost daily. Not sure about IE9 and others but usually such render bug are Browser issues that can happen, it's a dirty business so you get dirty things happening not only in tinymce. I agree Wywiwyg sucks and there's tons of problem, but I learned to deal with it, although never really happy. Mostly we have hard time teaching users to enter paragraphs and heading instead of breaks and bolds.

Also what would help is to see your setup. Are those pages locations and categories in one folder which is hidden? How much is the slowdown and how do you recognize it? What version of PW? I have a hard time believing that ~300 pages already is noticable. Though It maybe has to do with the render() method in the proxy gateway template which seem to cause the page getting rendered 2 times. Still not sure about many parts of the module, that's why it is stil considered experimental and I wouldn't recommend using it in larger and serious projects and be somewhat cautious about it's drawbacks. The module also hooks into the tinymce text fields to parse and replace urls which obviously gets in conflict with the Page Link Abstractor module by ryan which also does parse the same urls. There's just some edge cases where there can happen things you might not aware yet. Though PW is enough flexible and powerful to easily switch to another approach, but could hurt the projects urls and seo. At the end, only if people are using and testing it, it can be improved.

I haven't tested with more than a couple pages yet, and only built 1 simple 30~ pages website and haven't noticed any big slowdowns. Don't know if there's anything else than the search of pages that slows it down as there's quite some stuff happening on parsing urls. But of course the brute force method isn't that optimized for large sites as mentioned in the readme. Not sure how it could be improved without building a lot additional stuff like an index table. There would have to be some tests and experiments what would really help and I have no need for it ATM. Maybe someone else experienced can have a look.

Or $myPage = $pages->get(substr($repeater->parent->name,9));

You're right, but one little problem I found with current shop is that changing the product variation in Order Management is nearly impossible. Much easier if it's a child page you can chose from.

Using childrens pages for variation, and require at least 1, would be most simple codwise as it would need to changes.

I used repeaters to make variations and use the title of the repeater to make the variation title. I have a hook to generate the title from the variation type and properties (Product 50gr).

WillyC is right! How could I missed it So you can do: $form->setMarkup(array( 'list' => "<div {attrs}>{out}</div>", 'item' => "<div {attrs}>{out}</div>" ));

No there isn't a way. Try stick with it is all I can recommend atm.

Hack no good, tool better: foreach($templates as $t){ if($t->name == "admin") continue; $t->slashUrls = 0; $t->save(); } Done.