bernhard

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... 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!