Soma

I don't like the idea of having another TinyMCE instance outside core just for a theme's skin one have to maintain aswell. We've brought in external custom plugins and overwriting config on a per field basis and as we seen it's also possible to have the setting changed from the admin theme. It's up to the theme maker.

http://selectivizr.com/ works wonders if you care about IE6-8.

I don't really understand any or all off what you wrote in this thread. Impossible to help. Anyway. Are you aware that if a text isn't translated it will output the default language text instead? Just in case you maybe experience this and think it's wrong.

I actually also think it's a good way to include it in the theme globally. Most convenient. I really don't want to change core for the theme's extras. It's not a must anyway but wouldn't recommend as you everytime you make a wire update you have to take care of it. I've done it for quite some time with the TinyMCE inputfield and it isn't a pleasure at all. What if Ryan includes more TinyMCE themes into core distribution? Simple as that.

Nothing fancy, just load the .css always in the init() solves the problem. What are your plans on this module making it work without changing core jquery and php 5.3? Will you bring in the changes needed or should I also request a pull? I was also thinking how custom themes that already uses icons, that we could handle it so that with this module they will get disabled. I think overwriting css would be a way.

Great work Nikola. Love it so far. Just got trouble sometime seeing which are text fields to enter or just headers/labels. - Only thing that annoys me a lot is that it doesn't fit on my 13* 1280 laptop screen. - Also it would be cool if the subnav drop down would stay open if you're on a sub admin page. Also you haven't got the latest changes from default admin for inputfields. As Ryan canged quite a bit and the form-builder has some issues. On form-builder you see extra "submit" field text which should be hidden. And the entries edit screen has different inputfields markup. Of course this is a problem with all you other themes too. (happy fixing )

I don't know if it was this, but when I moved PW to a subfolder and access to admin didn't work and just show homepage, though no 404. I commited an update. Let me know if that fixes the issue for you.

Sorry I again can't reproduce this. Have you installed processwire in a subdir?

Sorry, I can't reproduce this.

..and maybe clear your cache and cookies once in a while.

Hello there update v1.0.3 I just went through all and release an new fix update for latest changes in PW 2.2.+ 1. Some issues fixed with new inputfields css and form builder mainly. Also added a overwrite of the TinyMCE skin used by default in PW. 2. This is now also in the default.php's header to set the "default" skin to all TinyMCE inputfields: ... <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) InputfieldTinyMCEConfigDefaults.skin = "default"; </script> </head> Hope this update doesn't introduce any new issues, but I've looked at all and √. Download as always from github. https://github.com/somatonic/teflon-admin-theme-pw2

Well you never can read enough and try So the correct version would be following. Here's what I implemented in my Teflon theme now. ... <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) InputfieldTinyMCEConfigDefaults.skin = "default"; </script> </head>

That's cool diego, I was just about to try something in the main.js of a theme. This might be the simplest solution. I want to add you can also make the o2k7 a silver or black skin variant <script> InputfieldTinyMCEConfigDefaults.skin_variant = "silver"; </script> In case anyone wonder why this works. This is because the InputfieldTinyMCE.js javascript has a config object var with that name "InputfieldTinyMCEConfigDefaults", so with this we can overwrite the config defaults or ones set via field configuration directly before TinyMCE is enabled and reading that config. Thanks diogo for finding this.

Soma to the rescue. Just add new line to "Additional TinyMCE settings" field in "TinyMCE Advanced Confoguration Options" under "Input" tab: skin: default or skin_variant: anything Enjoy!

The .css doesn't get added on the link dialog in TinyMCE where you can browse the page tree to select a page to link to. So the icon and badges have no styling. I think just adding the .css always in the admin would be ok.

Yes you can add "div" to the theme_advanced_blockformats. But then you can set a div, but not have paragraphs or headers inside. But what you could do is create tinymce html templates, you can select and insert. In this template you can have something like: <div class="errorbox"> <h3>Heading3</h3> <p>Text Paragraph</p> </div> It will insert this code, and you can then simply edit the content. To setup templates you add the button "template" and the plugin "template". Also add ,div[class] to the valid elements config string. Then in the Additional TinyMCE settings you add this on a new line: template_external_list_url: /site/tinymce/body_templates.php Then you create a folder /site/tinymce/ and create a body_templates.php (could also be a static .js) this will server as a proxy to add templates. So a list with js array. You should have a structure like on the screenshot. Then in the body_templates.php have this code: <?php include($_SERVER['DOCUMENT_ROOT']."/index.php"); ?> var tinyMCETemplateList = [ // Name, URL, Description ["Table Simple", "<?php echo wire("config")->urls->root; ?>site/tinymce/templates/body_template1.html", "A simple table."], ["Error Box", "<?php echo wire("config")->urls->root; ?>site/tinymce/templates/message_template.html", "Error Box."] ]; Now you can select the template via the template button in TinyMCE.

Took me quite some time to find a good solution to this issue, but I think I found one. Just updated module to 0.0.9. 1. It works now, and works much better with "Disable sub-folder for default language" option. 2. Improved some code also with the "Enable multi-langauge domains." setting, which also was suffering similar issue. It might be obvious but these two module options can't be used together. Also added notes in admin to be aware.

Ok I'll try again. Maybe I'm wrong here I'm not sure anymore. There's also mcmorry having his fingers on this.. Ah ok , with the option to hide the default language segement in url, I can reproduce hte 404 and it tries to load the real page url somehow. Well with this option turned off it's working. And the name (real url) isn't really playing a role. Well that's what I am looking at anyway. So I might be able to fix this.

Can you make any examples or show? I'm sorry you don't understand. I don't even understand myself sometimes. You only need to know so much... It doesn't matter what the name is, it will only chose the titles to parse the url generated by title field. But without knowing/seeing or even sitting in front of it makes it hard to tell what's wrong. This is in the nature of how it is done for now. There's no way around it for currenlty and implementing further additions like a name field for each language would be a good way, but not as easy as first seems.

Yes, the url is generated by slugging the language titles. So something in that direction it must be, but even if the title and name is different it doesn't matter cause it only takes the title and never the name to brute force to the page. It's a little more complicated and quite a lot of things going on already. Can you look at the module PageName inputfield. And see if you entered all cyrillic chars convertion you'll need. This should always be the first thing to prepare when installing PW first time. I'm not sure it is in your case. I can't reproduce any 404 like you mention, and it works ever since 2.2.3 and I got it running locally since then. It still works with 2.2.7. Ok, one thing I recognize now is the option to hide the default language segment. When I turn that on it doesn't switch language to the default anymore. I'm still investigating and don't see a simple solution yet, and I think best is to leave that option out and stick with language segment for all. Also I still recommend to take care with this module and once you set it up, never try to change anything once live. It is still "beta" and should be not used in serious bigger projects unless you really know what you're doing.

Actually it's now in there without advanced. And it should work for all fields I think.

Lol, Ryan I'm just kidding here. I oversaturated, ignore me.

Maybe I'm missing something, but currently in latest PW you can set all fields to "required" built in.

I see a big mindplay - ryan war, about what should be there and what not and how. Mindplay, Ryan has an answer to everything and it actually always makes sense, meanwhile he's a stubborn guy (which is good imo) as I knocked my head against him a couple times already. Peace guys!

What if you try it out and see? I see why you did that. The way with InputfiledMarkup it creates a new container below the dropdown simply. There's no real problem I see with having them separated. But following the Inputfield strategy, you could add a InputfieldFieldset (as mentioned already ealier) and add the select and the icon markup to they group together. The way you did it is also possible obviously just wasn't working since I don't run 5.3 locally yet. And I think it's easier to follow using inputfields. I know. Well I wasn't trying, I just quickly replaced them with the old event methods so it works without updating the jQuery core (which would break PW admin). I agree it would be cool to use latest event methods, but this isn't yet possible so.