Soma

Any news on this? How far is it translated already? Especially it would be useful to have translated Comments module and anything that could be shown on front-end. I think they're all missing yet. Can this @underk repo be added to the French pack already on modules.processwire.com instead of the download link to this forum. I didn't realize there's a repo on github already.

Hey Alessio, are you still maintaining this or anyone interested in? Not only for own needs I think it would be great to have some up to date version of Italian translation pack. Especially regarding comments module and error messages that could be needed for front-end also.

... because Fredi renders/construct outputs the form itself, using ProcessPageEdit to buildForm, just the part you changed is not involved.

No Ryan, I reported that they were not visible in modals where modal=1 is used cause they're were cut off, but it seems it's gone in latest admin theme version, but not sure why or how. Yeah I also preach that, but I meant getting along with the project/site I'm trying to develop. Well, it was wierd with the role thing, and costed my editors time and frustration, in that they couldn't edit when they actually wanted Just debugged half hour why Fredi modal (renderAll()) wouldn't now show WireTabs. Turned out you changed the ProcessPageEdit to init the script from an inline script: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L135 So simple changes like this can be nasty, and break other modules that depend on it

BTW, I'm using Fredi a lot lately, and noticed that the WireTabs don't work there anymore when doing a renderAll(), which renders complete page edit form. I'm not sure which part is responsible for, but lately I find quite a lot of those glitches and wierd behaviors of PW, and find myself debugging and trying searching rather than developing. Latest was I updated a install 2.3 to latest 2.3.13 and the editors couldn't edit content anymore cause the "edit" action was gone. After not finding abvious reason, I saved something with the roles or something and it was working again.

@adrian, that config is a monster you know ok added style to overwrite max width of popup. Pushed an update with some translations added

I just noticed that the complete ACE editor is bundled with TextformatterHannaCode. Wouldn't it be nice to make it a separate js module and use it if it's installed? Also there's already a ACE editor fieldtype from Adam. Since ACE editor source comes with 1million! files I think it would be the way to go. Much like jQueryDataTables or Magnific etc.

The only time I got a strange effect was when messing around with a module and has 2 of the same installed I think when I moved AdminTheme module from core to site modules and tried installing that, there was no "Core" anymore.

I would lol if they get disqalified.

It's only visible for the hard'core'.

Same for links that have a class added and if reopened in link modal and changed the link lost the class added before. This is ever since. And with image too. Think there was some thread about it.

There's no $page->urlSegment only $input->urlSegment. You problem is not a bug. You're using a context in a Textformatter, but it's of course in the context of the current page as I understand what you saying. So you would need to do something differently. There's many ways and solutions I guess, but without seeing your Textformatter it's hard. One would be to set the $page to the one you render the field from and set it back to the page before. etc.

You can't login user, as you don't know the password. setCurrentUser does not login but set the current user, so if you do that for every request it's like he's logged in. To you original question I have no idea. Not something usual.

My take if($page->parents->has($section)) ... if($section->find("id=$page")->count()) ... // direct parent-child if($section->children("id=$page")->count()) ... if($page->parent === $section) ...

You're on the right track, but not sure what all would be required to make ckeditor work on front-end. There's many js config vars used in the backend for certain fields like TinyMCE or CKeditor. If you look at admin source code you'll see the var config = { .... } in head, that can then be read by js scrpts and plugins. All this stuff is dynamic and pulls configs needed from the field configurations. This is populated via $config->js(); and output in the admin theme (default.php) before any scripts are includes. Also the scripts and styles needed for a particular Inputfield is loaded via $config->scripts and $config->styles, this is then again output in the admin theme (default.php) in the head. All these play together to make admin backend work in it's modularity.

What do you expect? Well it does only set the current user for this request and not log in.

@stefan, Just wanted to mention that it's generally not a good practice to use the title for such things. marke=Masita|Kempa May cause trouble depending where and how you use it. If for forms and filters you could just use id or name instead of titles. marke=2133|2134 There's many ways to do this stuff and depends what you want/need. //some form ... $options = $pages->get("/marken/")->children(); $select = $modules->InputfieldSelect; $select->attr("name", "marken"); foreach($options as $opt) $select->addOption($opt->id, $opt->title); echo $select->render(); // and later maybe $markenids = implode("|", $input->post->marken); $products = $pages->find("template=product, marke=$markenids); // marke=1231|1231|1233 ...

It would be correct: $sanitizer->pageName("Größen", Sanitizer::translate); No it's not dependent on special thing. It's used to translate titles to the name. Nothing to do with translations. This was added at some point around 2.3 after lots discussion and isn't documented on API section (yet) but on cheatsheet http://cheatsheet.processwire.com/?filter=pagename.

What "is not working" ? That means? It works for me fine if you mean the setCurrentUser(User). Only thing I can say is make sure you're having a user actually there with $u. If not, id='42' looks wrong to me and should be id=42

Thanks for the reminder. I'll have a closer look again when I get bandwidth.

I'm using this a lot and it works also with latest PW, even with TinyMCE (multilang textarea). Though I'm not sure if there's any potential issue.

Actually $page does resolve to the id here anyway so no difference.

Small correction to Ryans example, it would be $users->setCurrentUser($u); and maybe not use $user var but $u, since you would overwrite the $user var: $u = $users->get($id); .. $users->setCurrentUser($u);