Soma

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.

Setting template filename only works if it starts with full root path. Make sure your paths are correct. The root path you have you can see with: $this->config->paths->root So $this->config->paths->templates . "view/mytpl.php"; works fine in a hook I don't think you can set the template filename in the template for the page as it's already rendering it. Also $event->return = $page->template->filename; isn't needed if it's in a before render hook.

What's your code?

Minor correction: it's wire/modules/InputField/InputfieldInteger.module

Hi Joe. A simple search via google (processwire.com hide settings tab) found my thread a while ago: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/ Here's another example doing it differently: // in a autoload module like HelloWorld.module public function init(){ $this->addHookAfter("ProcessPageEdit::buildForm", $this, "buildFormHook"); } public function buildFormHook(HookEvent $event){ // get page edited by ProcessPageEdit $page = $event->object->getPage(); // conditions if(wire("user")->hasRole("superuser")) return; if($page->id == 1039) { // the form InputfieldWrapper returned by ProcessPageEdit::buildForm() $form = $event->return; // find the desired InputfieldWrapper's and remove them from the form $fieldset = $form->find("id=ProcessPageEditSettings")->first(); $form->remove($fieldset); $fieldset = $form->find("id=ProcessPageEditDelete")->first(); $form->remove($fieldset); } } This works fine in PW.

Can you also do this in your OS? I don't think it's even possible.

Click the dot or star in front of title.

I haven't really investigated further but stumpled over this: In a multilanguage setup (3 languages) I have a hook to do thing on language fields. In a autoload module $this->addHookAfter("FieldtypeTextareaLanguage::wakeupValue", $this, "hookWakeupValue"); This results in PW calling wakeupValue() 3 times for each field. Is that because of there's 3 languages? I don't understand why this is so and wonder if that's a result of the language system? I'm not sure why this is needed and think could be avoided? It's not that the values change, it's always the same field and language values. As a result if have to implements checks to avoid getting the intense code called 3 times, it's getting clunky.

Ok so now that would be the 4th integration attempt ( I still haven't get to share mine )

What if we make the animation able to configure so you could set a time or turn it off with 0. I'm sick of the animation taking long time when it needs to open a branch on 3-4 level. something like in the module settings of ProcessPageList or through $config? $config->pageListAnimationDuration = 100; $config->js(array('pagelist' => array('pagelistAnimationDuration'=> 0)));

All seems have to do that you actually append the sidebar pages to the homepage items.