bernhard

so what changed since your example here? and how could i detect clicks on buttons?

no, thats not the reason. i don't know why, but $input seems to work! i was also expecting it NOT to work without $this, but it works for $input->get... <?php namespace ProcessWire; $out = ''; bd($input->get); bd($this->input->get); bd($this->wire->input->get); bd($input->post); bd($this->input->post); bd($this->wire->input->post); return; the one on the top is the $post and the one on the bottom the $get. I tried it also on a different install. Same behaviour. Really strange... no idea whats going on

Hi kongondo, I'm sorry that I have to say that, but I still don't like the solution. It took me some time to understand all the settings, read the instructions carefully, paste in some file paths, ended up with some errors (I pasted the old paths with different root from the autofill for this field)... I ended up putting this replace hook in my site/ready.php - i guess this will save me, and you, and maybe some others some time... /** * replacement for the original runtimemarkup render method */ $wire->addHookBefore('InputfieldRuntimeMarkup::render', function($event) { $event->replace = true; $field = $event->object; //so that $page and $pages are locally scoped to the eval $process = $this->wire('process'); if($process && $process->className() == 'ProcessPageEdit') $page = $process->getPage(); $pages = $this->wire('pages'); // render files that are related to this field $root = rtrim($this->wire->config->paths->root,'/'); $path = '/site/modules/FieldtypeRuntimeMarkup/fields/'; $file = $root.$path.$field->name; if(is_file($file.'.php')) { // we found a file in the modules /fields folder, so render it $str = wireRenderFile($file, [ 'page' => $page, 'pages' => $pages, ]); } else { // no early reaturn because we load assets later if(!$this->runtimeFields) $str = ''; else $str = eval($this->runtimeFields); } // load assets related to this field if(is_file($file.'.js')) $this->wire->config->scripts->add($path . $field->name . '.js'); if(is_file($file.'.css')) $this->wire->config->styles->add($path . $field->name . '.css'); //since we are dealing with custom PHP code but also want to make sure that only markup is returned //if eval() returns anything other than a string or an integer, we throw an error (e.g. if an object or array is returned) $event->return = "Place your files here: $path<a>{$field->name}.php|css|js</a>"; if (is_string($str) || is_int($str)) $event->return = $str; else $this->error($this->_('Only strings and integers should be returned by your custom code! Check if your code is valid.')); }); With that method the setup is as simple as it can get. no clicking around, no pasting in wrong filenames, no error messages if there is no file... create a new field place it in your template place your files to /fields/myfield.php|css|js ---- another question that cost me quite some time already do you have any idea why this simple code does not work? if($input->post->submit_save) echo 'saved!'; else echo 'not saved'; using tracy i see that $input->post has no data while $input->get has the url params... also your example from here does not work any more: help would be highly appreciated

hi tpr, seems that the move up/down icons overlap the delete icon making it impossible to click on it. do you need more information to reproduce this? aos 1.5.0 and pw 3.0.68

making progress on this but there's still a lot to do until it is releasable as a module (proper documentation mostly)... sneak peak what's easily doable: a todo-app definition is as easy as that: /** * show table of todos */ public function executeTodos() { // create form $form = modules('InputfieldForm'); $form->action = './'; // add new project $b = modules('InputfieldButton'); $b->attr("id+name", "addTodo"); $b->addClass("ui-priority-primary pw-panel pw-panel-reload"); $b->value = __("Neues Todo"); $b->attr('data-href', pages(2)->url . 'page/add/?parent_id=' . pages('template=todos')); $b->icon = "plus"; $f = modules('InputfieldMarkup'); $f->value = $b->render(); $form->add($f); // table $t = modules('InputfieldRockDatatables'); $t->attr('id+name', 'manageTodos'); $t->rows = pages('template=todo'); // define the table's source rows with one selector $t->ajax = 1; // set table mode to ajax loading making it possible to reload data via a simple $table.ajax.reload(); [...] // remaining $col = new dtCol; $col->name = "remaining"; $col->title = 'Tage'; $col->className = 'minwidth'; $col->data = function($page) { if(!$page->deadline) return ''; $now = new \DateTime('now'); $then = new \DateTime(); $then->setTimestamp($page->deadline); $days = $now->diff($then)->format('%R%a'); $color = config()->colors->lightred; if($days > 0) $color = config()->colors->lightorange; if($days > 7) $color = config()->colors->lightgreen; $obj = new \stdClass(); $obj->display = $days; $obj->colorBars = [ [1, $color] ]; return $obj; }; $t->cols->add($col); [...] // add field to form $f = modules('InputfieldMarkup'); $f->value = $t->render(); $form->add($f); $out = $form->render(); return $out; }

looks fine to me. try it with an empty pdf and the most simple headers & texts possible. maybe your header is just too large and it cannot shrink it (because it's not intended). mpdf is often trial&error

you should just be careful when installing pw into a subdir because sometimes this can break paths... for example if there is any link pointing to the root ( "/" ) it would NOT point to the right direction, because it should actually point to "/api/" you could overcome this using a subdomain. if thats possible in your case i would recommend using api.yourdomain.com instead of yourdomain.com/api/

see the docs and examples on that page: https://mpdf.github.io/reference/mpdf-functions/addpagebyarray.html $mpdf->AddPageByArray(array( 'orientation' => 'L', 'mgl' => '50', 'mgr' => '50', 'mgt' => '50', 'mgb' => '50', 'mgh' => '10', 'mgf' => '10', )); mgt = page margin from the top (where regular text starts, in the example it would start 50mm below the top) mgh = margin for the header (where the header text ends, in the example it would end 10mm from the top)

looks like somebody starts liking the file option yes, that's what i want i try to explain what i was talking about in the last 2 postings: imagine you are working on a project with some runtime markup fields... it starts with easy markup, some html. you create your field, set the option to render a field in a specified folder and you're fine. lets say we store it in RM/fields/myfield.php; so far so good. imagine you continue working on your project... your project grows and your field needs some more styling. we need some easy CSS rules for that field. so what to do? option now: leave your IDE open just another browser tab go to the backend search the field go to the settings put in the path of the CSS create your css file (RM/fields/myfield.css) put in your rules my way how i did it with my render method for several fields: create your css file (we have a myfield.php, so create a myfield.css in the same folder) put in your rules that's A LOT easier and fool-proof imho. the problem with your "we have that option of including files with the same name already" is that it throws an error when the file is not present. imho that harms more than it helps, because the problem is that you can NOT choose this option while setting up the field at the moment, because it would always show the error as long as you don't have (don't need) a css/js file. i would really really vote for one global option: this setting could hide all other inputfields, you would not have to change any of your options and have a solution for everybody. hope that makes my point more clear now

just wanted to share a screencast of one old website with a kind of widget-visibility-ui that could serve as inspiration. it's not good enough to share as a module, maybe someone wants to take it further -> pm

One thing that stole me some time to find out is when you create pages via the API you need to take care that all languages are active on your own as they are inactive by default One little hook does that trick though:

thanks for your reply! I think your answers are totally out of context some times. For example specifying a root path is not added security compared to my suggestion of having a fields folder inside the runtime markup module. but this point will be fixed when we have another option, so thank you for taking that into account Regarding the automatic include of js+css files: I really disagree about that. Your point about breaking the edit screen has nothing to do with the way the file is included! I would also break the edit screen when i include a broken JS file that is specified in the field's settings. IMHO braking up all into 3 config fields adds the possibility of errors because you can easily have typos etc. if you have your root path for the field (wherever it is, i understand your point about modules and templates) and you have a my_field.php file there. its much more secure and error-unlikely to just put a new file in the same folder (having it grouped in the filetree because of the same filename beginnings) and have that load automatically when present. i don't think that the error message is necessary or helpful for the USER of the field, because if something does not work as expected, you can easily do an alert('working') or the like. I think those error messages only help you as a DEV of the module for finding bugs while writing all the include paths etc. OK... given that you set your field to include a file in a custom directory it may help to get an error (for example to find typos)... i just didn't think of that too much because i only had one folder and that was really fool-proof to place a file there. considering the fact that this could be helpful sometimes and that imho it is NOT more unsecure to include the js+css automatically if present i would really like to see that as a third option too thank you for your time - please don't be mad about me picking on so little things... that's just the proof that i'm using your module a lot those days

hi @kongondo I just tried the dev version and have 2 questions: what is the reason for specifying the root path as /templates or /modules ? Why not a folder inside the RuntimeMarkup's module folder? like /FieldtypeRuntimeMarkup/fields ? Ok, i can specify an alternate filename, but imho that is an unnecessary step and it would be preferable to have this at least as an option. I try to keep the templates' and modules' root folders as clean as possible... edit: of course that would not be a good idea because module updates would wipe all code files in this folder! Second thing that i find more annoying than helping is the js and css file include warnings / settings. Why do i have to select if there is a js/css file present? Why does it not include a js/css file automatically if one is present. Imagine you are working on a runtime field and want to do some minor css changes. you are in your IDE and you would just have to create a new css file with the name of your field. But as it is now, i would also have to change the field's settings. Thats some more extra clicks that i don't understand why they are necessary if my proposed render method did not have this drawbacks. maybe there is a reason for that and i would be happy to hear it thanks for bringing my ideas into your module though!

no idea if that could work, but maybe you could use htaccess rewrite rules to achieve something like this?!

Thank you! That sounds like a big issue... And very strange. Hope you find it out soon

@adrian do you think you can have a look why the hooks inside ready.php are not applied when executed from the tracy console? i had an issue again today... i wanted to test a simple property hook and got an error. i think that's quite a big issue because imho the panel code should just execute as if it were executed inside a template or module. and i guess testing hooks, functions, creating pages via the console etc. is a VERY common usecase for tracy-users... // get group of given fbrole $wire->addHookProperty('Page::group', function($event) { d('test'); $page = $event->object; if($page->template != 'fbrole') return; $event->return = $this->pages->get(1634); }); log (first from ready.php, then from init.php):

Hi Ryan, This will be great and handy in many cases I guess, thank you Some questions that come to my mind: Will it be possible to choose a subset to import? That could be great for doing backups and having granular control over what to restore. Not sure about this, that's why I'm asking: what do you think about adding the possibility to include modules to the export? It could be taken as some kind of "site profiles", but much more flexible. For example you could build a master site profile, install a new sandbox site, import your profile and during the import you could choose which pages and which modules to import. Hmm.. thinking about it it would also be nice to have the same feature for templates as a next step. Maybe that goes too far, but maybe that's already your plan for the long run? Would be interested to hearing your opinion Have a nice weekend everybody!

as a next step i would recommend you try the processhello module soon! i was somehow afraid of building process modules but it really made "click" in my head once i got it. and it's often a lot easier to create a processmodule than hooking and modifying the page edit forms or messing around with runtimemarkup fields. give yourself 30 minutes, copy the processhello to a sandbox site and then see somas thread about building forms via the API. this will warp you to the next level using the InputfieldMarkup you can build your own custom HTML easily that has the look&feel&features of all the other admin fields: public function ___execute() { // set headline + browser title $headline = __('Awesome!!'); $this->wire('processBrowserTitle', $headline); $this->headline($headline); // create form $form = $this->modules->get('InputfieldForm'); $form->action = './'; $f = $this->modules->get('InputfieldMarkup'); $f->value = '<h2>wow!</h2><div>you can do anything now with that knowledge ;)</div>' $form->add($f); return $form->render(); } untested

take care, it's addictive

thank you @szabesz i'll comment this there

thank you adrian, i can confirm this behaviour! it turned out that my problem was a combination of two 1) like you mentioned the hook does not get called when called from the tracy console - that's weird and i think that's somewhat critical as it could lead to problems (not doing things that you would expect, doing things that you would not expect; and hard to see sometimes!). 2) even in the init my language hook didn't work. turned out that this works: // set all languages active automatically $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); foreach ($this->wire->languages as $lang) $page->set("status$lang", 1); $page->save(); }); while this does NOT: // set all languages active automatically $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); foreach ($this->wire->languages as $lang) $page->setAndSave("status$lang", 1); }); no idea what could be the reason for this #2 is somewhat offtopic. but what do you think about the tracy hook problem? do you think this problem is more related to tracy? my init.php bd('init.php'); // test tracy $wire->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments(0); bd('saveReady in init.php'); bd($page->id); }); my ready.php bd('ready.php'); // test tracy $wire->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments(0); bd('saveReady in ready.php'); bd($page->id); }); after loading: after executing the code inside the console:

Or you modify your pagenames (eg john-doe-url) then you can use the URL segment and append the "-url" to your filter. In general it is often a good idea to have all persons under one parent and do the grouping via pagefields (or select options). But maybe it's better like you did in your case. This was just my experience

It would also find John John and doe doe, but I guess that's unlikely and negligible, so maybe it's the easiest solution

hi everybody, i have a weird problem regarding hooks. there was some unintended results so i started to make it really simple and see what's happening. this is what i came up with: i have this simple hook inside /site/ready.php $this->addHookAfter("Pages::saved", function($event) { $this->log->save('debug', 'saved hook'); }); when i save any page in the admin i get a new log-entry. so far, so good... when i put this inside my home.php template and visit my frontpage: home.php <?php $page->of(false); $page->title = 'set by template'; $page->save(); ...it changes the page title and runs the hook (i get a new log entry). but when i use @adrian s console of tracydebugger with this code: $p = $pages->get(1); $p->of(false); $p->title = 'set by API'; d($p->save()); ...it returns TRUE, it saves the page, but it DOES NOT call the hook. it does not save a new log-entry. I wasted more than an hour now to find out what's going on here. please could anybody of you bring light into that weird problem? in the example it is only a log-entry, but i have several saveReady or added hooks that seemed to work but actually didnt for example it does NOT activate languages for pages that i created from the API (https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/?do=findComment&comment=147564). that's really critical problems. am i totally misunderstanding anything? thanks for your time!

@Zeka this wont work because it means that either first_name or last_name has to contain all the words (john doe). also something like this would be not exactly what you are looking for, i guess: first_name|last_name=john|doe ...because it would also find "hans doe", "maria doe", "john müller" etc. i think the best is to populate a hidden search index field with what you want, for example: $wire->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments(0); if($page->template != "yourtemplate") return; $page->searchindex = "{$page->forename} {$page->surname} # {$page->surname} {$page->forename}"; }); and the selector $pages->find('searchindex~=john doe');