-
Posts
6,808 -
Joined
-
Last visited
-
Days Won
159
Everything posted by Soma
-
Just wanted to note that this module kinda falls apart with recent changes in PW (2.3.5 dev) dates formatting doesn't work anymore/or never had all labels are separated by "," suddenly after updating it would be nice to either integrate something more advanced into core that allows for more control over labels. Ryan? I spent too much time tweaking and debugging with this modules and my own. Images labels, page fields, dates etc.
-
How to set page name in different languages through the api?
Soma replied to lpa's topic in Multi-Language Support
I just ran into this myself. I can set the language page names when creating a page or in a Pages:added hook, but when using a Pages::saveReady hook it doesn't work. Simplifyed example: in a Pages::added hook it works setting the page names. ... foreach($this->languages as $lang){ $lname = $lang->isDefault() ? '' : $lang->id; $default = $this->languages->get("default"); $time = time(); if($page->title->getLanguageValue($lang)){ $page->set("name$lname", $time . "_" . $page->title->getLanguageValue($lang)); } else { $page->set("name$lname", $time . "_" . $page->title->getLanguageValue($default)); } } $page->save(); After page is created and in a Pages:saveReady hook the following only sets the default page name, the alternatives stay untouched. ... $page->of(false); foreach($this->languages as $lang){ $lname = $lang->isDefault() ? '' : $lang->id; $default = $this->languages->get("default"); if($page->title->getLanguageValue($lang)){ $pageName = $prefix . "_" . $page->title->getLanguageValue($lang); $pageName = $this->getUniquePageName($page, $pageName); $page->set("name$lname", $pageName); } else { $pageName = $prefix . "_" . $page->title->getLanguageValue($default); $pageName = $this->getUniquePageName($page, $pageName); $page->set("name$lname", $pageName); } } $page->skip = true; $page->save(); The values for the $pageName are all correct but nothing seems to work. Edit: just changed the hook to Pages::save, and it works now... no idea why -
A bit more information would be good. What does the error logs say? NO that cache is just to store the json feed locally instead of loading it everytime. But has nothing to do with the rest of PW.
-
This also seems interesting as maybe also seen: http://madebymany.github.io/sir-trevor-js/
-
I'm trying to find pages by name. I can't get a page by using it's alternative page name. Assume it's the same page: $p = $pages->find("name=namefor_default"); // this works as normal $p = $pages->find("name=namefor_german"); // this doesn't Doesn't matter what language the user is viewing. Also trying to do something like "name$langID=blabla" just throws error that name1013 isn't a field. I tried all different things but no chance. This makes it kinda hard to build multilanguage page structures that would require to find pages using the path or name i.e. using urlSegments etc. Edit: Only chance seems to use "path=/de/full/path/to/namefor_german/".
-
Thanks adrian, it's that color picker swatches below the colorpicker stopped working. When clicking nothing happens. THis is with the new theme and after changing back to teflon or old default it works, and there's no obvious reason. I haven't tested in the latest as I simply have no time.
-
I just pulled the latest version and I must say it seems falls apart for me in various parts. :/ It seems there's a lot of changes that make custom modules not work anymore or have side-effects in some way. I have noticed that now the page tree labels are separated by "/" or "," and using custom page list markup module I now get "," all over. Before latest update: After latest update: Also as mentioned earlier my color picker field stopped working partially with new version and given up on it trying to find the issue (nothing obvious and have no bandwidth) Also after changing to the new admin theme on a complex site I'm working on with multilanguage I changed back after 5 min to my teflon as it's so loud and "messy" I can't work with it. The old default theme still seems a lot better. I'm sorry to say this and appreciate all the work Ryan put into this. But it really all worries me a little not only the admin theme, but also that there's changes done now that seems to break some 3rdparty modules and I'm a little worried. I'm sure only some are affected but still there's now troubles ahead maintaining all those that do break. After all I know there's some transition happening now and it's the price to pay for using latest dev, but I have no choice as to some bug fixes are only available there especially for multilang features.
-
How to set page name in different languages through the api?
Soma replied to lpa's topic in Multi-Language Support
$lalias = "the-name-of-the-page-in-english"; $english = wire("languages")->get("english"); $lalias_name = wire("sanitizer")->pageName($lalias); $page->set("status$english",1); $page->set("name$english",$lalias_name); $page->save(); -
Actually you need both of these, urlSegments to render those pages on a different level, and the hook is just to conveniently modify the path (esier than manually createing them). I don't see where duplicated content is a problem. EIther use canonical urls, or take care of it with a redirect or some hooks. But if you never have links to those (real locations) you won't have them visible anyway.
-
Wanted to mention something that is even more a problem with this theme (as it was with the current default) If a field or fieldset is collapsed, it's hard to see or easily overlooked. It looks much like a some sort of header for the following fields. I have no idea how to solve that.
-
Yeah I know about the issue, but haven't been able to solve it in a convenient way, also now it has changed since then to outputformatting on which is different for image fields. Kinda have to take a look again, but not sure I'll be able to do it any soon. So if somebody gets a chance. Adrians' solution wasn't really cutting it I think when I tested it back then and requires more things to consider.
-
1. The blocks are saved in admin branch. I had it in the root a while and that's why you get the behavior as it's not viewable if they're in the admin. 2. As said in the readme, the blocks get deleted when you delete them 3. There's possibly a check missing (As with the page field php code.), I think I've already taken care in my version.
-
Updating the module to 1.0.3 it doesn't recognize paste in CSV data I get "Missing required CSV file/data", the file upload works. Could it be that the folder for that page is /-1006/ and it doesn't allow to use file_put_contents() as it's protected by htaccess? It tries to put in "/home/.../site/assets/files/1006/data.csv" Also the duplicate option doesn't rename names to "name-n", it just throws error and names them "-n" SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'ilnau-5870' for key 'name_parent_id' Quick look at #404 $page->name = $this->getUniquePageName($pageName); $pageName isn't set, it should be $page->name
-
Love it.
-
I'm not sure about other ways. I haven't thought about it and not 100% sure what you thought would be the way. And there's already a fallback (setting on the language field) to show default language value if empty. Maybe it would be god to start studying where this happens and how it's done?
-
Ryan is open to add hooks when requested and it makes sense or there's a need for it. Language modules are relatively new and not many things has been done with it so it's just a matter of asking. I also am working with languages and recently thought the same while looking at the LanguageSupport modules. You could for now just make them hookable by putting ___ prefix.
-
Thanks for this comprehensive writeup. I wanted to mention that there's something planned for 2.5 http://processwire.com/about/roadmap/ I think it's challenging and not easy to tell how all this should work, especially if you're not aware of all the inner working of PW. Cloning has been discussed and there was some effort to try to find or implement something. There's, as you mention a lot to consider and walls you will be facing. That's true but there's ProcessPageEdit::getPage() that you can access the currently edited page, or using the GET id. I think Fieldtype::sleepValue() would be maybe a way to hook into values of fields before saved to db. Inputfield::processInput being another that is used to process values before going to sleepValue or sanitizeValue (I think). Not sure what really would be the way to go. PW is flexible and maybe you build content of pages from different approaches than just on one page. I can't think of reliable ways to handle all types of setups, custom fields and it's varying data. Maybe there would be a way to define some interface that fieldtypes or modules can/should implement to handle custom stuff, but I'm not seeing through this and just randomly thinking.
-
It's also to know what to search I remembered this and looked at FormBuilderProcessor.module, I found this in the FB forum with "formSubmitSuccess" http://processwire.com/talk/topic/4188-managing-successerror-messages/?hl=formsubmitsuccess#entry41151 In case of FB you may want to only hook if the form is submitted successful and you could do this in yet another way (yeah it's not easy) function hookForm($event){ $form = $event->arguments('form'); // as per the argument in the hooked function could also be arguments(0) $field = $form->get("file"); // familiar? print_r($field->value); // file field // do stuff } wire()->addHookAfter("FormBuilderProcessor::formSubmitSuccess", null, "hookForm"); echo $forms->load('contact-form')->render(); Or FormBuilderProcessor::formSubmitError accordingly It's all a little different with formbuilder and I had to try and lookup myself. You can't hook, at least I couldn't find out how (maybe Ryan maybe knows more) into the inputfield processInput directly as with regular InputfieldForms.
-
NP manol. I?m just kidding. BUt this would be more of a formbuilder support question. FB is special in that it needs other methods: function hookForm($event){ $form = $event->object; $file = $form->get("file"); print_r($file->attr("value")); } $forms->addHookAfter("InputfieldForm::processInput", null, "hookForm"); echo $forms->load('contact-form')->render(); But I'm not making any money out of form-builder (but Ryan) so I'm not too keen on helping out. I don't mean it really... Also there's some threads about this exactly and you better search via google as mentioned.... Edit: Ok, maybe not so good searching via googel as the form builder forum is private
-
Thanks adrian, I have a feeeling I'm repeating myself over and over
-
maybe try something like this? to get the field it sometimes easiest to use a find() or maybe simply $field = $form->get("name=reconocimientos"); function hookEmail($event){ $file = $event->return; echo "value: ". $file->value; } $form = $forms->get("reconocimientos"); $field = $form->find("name=reconocimientos")->first(); echo "field: " . $field->name . "<br/>"; $field->addHookAfter("processInput", null, 'hookEmail'); echo $form->render(); the hook needs to be before you render the form too. but not sure what you want to achieve
-
I'm currently migrating a large 3 languages site to PW couple thousand pages...
-
I don't know who thought it would be good idea.... Just one word. Annoying! It only sounds useful but it's annoying and causes a lot of "arrrrg". Just imagine clients, when even I constantly 50 times a day get caught by it. Can we remove it or at if kept, make turn it able to turn ON in a config? I don't know why it was added and was never in for it. Thanks
-
I'm doing it also here https://github.com/somatonic/BlocksContent/blob/master/BlocksContent.module Works fine. Can't say except that the path has to be correct and file exist or it will ignore it. Also maybe the context or hook is different in your code.