bernhard

Just pushed an update to make the currently edited page available to the rendered PHP file: // before $editPage = $pages->get($input->get('id', 'int')); echo $editPage->path; // now echo $editPage->path; thx to @psy for the idea

If that's easier that would be even better because this screen shows all the used arguments as well. But it's really not that important ?

Hi Adrian, thx for your time ? Simple example: // ready.php include('demo.php'); // demo.php bd('fired'); Exactly ? Thx, didn't know about that! That already helps. So for me it would already be great to get a trace() shortcut for that ? And it would be awesome if the "file" entries in the trace would be clickable links that open that file in the IDE. But I don't want to steal your time, so if others don't find that useful I'd be happy with a simple trace() version ? Thx!

Hi @Lmwt, welcome to the forum! Did you go through the hello worlds tutorial step by step? BTW: You know there's someone in Vienna that knows ProcessWire quite well and is always willing to help? ?

Nice to know, thx. I haven't been working with pdf for some time but I remember I've always had issues with the correct file paths... I think paths did somehow not work, but not sure. I think they didn't work in older versions of mpdf. There you had to define relative paths (not public urls) to a root path that was set in the module's config. Maybe things have changed to the good ?

I'm using ->url in several spots in my projects and it works. Maybe he messed up something else or maybe our setups are just different. The screenshot looks like he is already using a full disc path /var/www/... and not an url site/assets/... @August Make sure the file exists on your server and then just try different paths/urls and see which one works for you. Start doing it manually without using pw variables and once you have one working example expand on that one.

Hi @eelkenet, thx for sharing ? Did https://modules.processwire.com/modules/range-slider/ not work for you or did you need other features? Would be nice to see the differences between your modules. We also have this one:

$img = $pages->get(1)->images->first(); // adjust to your setup $pdf = $modules->get('RockPdf'); $mpdf = $pdf->mpdf; $mpdf->WriteHTML('Hello World ' . date('H:i:s')); $mpdf->WriteHTML('<div>Showing image ' . $img->url . '</div>'); $mpdf->WriteHTML('<img src="' . $img->url . '">'); $pdf->save(); Does this work?

They CAN certainly do. But it's not plug&play, it will need some more or less simple coding ?

Looks like a good use for $page->meta ? If you stored the data raw (userid + timestamp) and created the german string + date on render you'd be safe for future updates (multilanguage for example) and you'd be able to change the date time format instantly for all files.

I don't see a problem and that's exactly how ProcessWire itself does it...

That's not a recommendation and a little offtopic, but that sounds a little bit like what I'm always doing with grids (be it RockGrid or RockTabulator). I'm storing everything as pages and I'm listing everything in a grid. That has the benefit of being extremely flexible and extremely user friendly. Users can filter, sort, export, etc and you can colorize and add icons to everything. And (thanks to PW) you can add as many and as custom fields as you want (uploaded by, last edited at etc). For example I'm handling invoices, each invoice is a pw-page and has several fields (date, pdf, date_due, date_sent, etc). This might theoretically also be possible now that we have the new custom image fields, but as ryan mentioned there might be some situations where things will not work). And pages will work ? I'm then creating a Tabulator to list all invoices on a grid (usually that's a lot better for users than finding their way through the pagetree). That's a simple RockFinder2->find(). On a client's edit screen you can even re-use this grid and show the same information but show only invoices that belong to that client. That's a simple $selector['client'] => $client in the grid's data setup file. Using repeaters or file fields is usually a lot more complicated in the long run. IMHO they are great for websites or website content (like showing bullet points of one page or showing a handful of downloadable files on a blog post), but as soon as you are doing some kind of database application it's best to avoid them as much as possible and stick to the "pages and page relations paradigm" using regular pages and referencing them via page reference fields. -- If you really want to show that information directly on the file entry I think that's nothing that the core needs. Just hook in the field markup and show that information. IMHO it does not really matter where you store that info. It could be a custom db table, a hidden textarea storing a json string linking filenames to additional data. Or it could be the new file fields (which - I guess - technically would be quite similar to a solution that uses custom pages + fields and RockTabulator). Maybe you could even use https://processwire.com/api/ref/page/meta/ instead of a hidden textarea + json. Never tried it though ? Sounds like $page->meta + hook could be worth a try ?

Nope, thx, that looks great ?

That can mean lots of different things... Show it directly beneath the image, show a filterable list of actions who uploaded which image to what page etc.; Depending on the exact goal the best solution can be totally different from one situation to the other.

For me: Unfortunately no ?

Why? What is your exact goal? Maybe a simple file log would be enough? user foo added image foo-img-1.jpg user foo added image foo-img-2.jpg user bar added image bar-img-3.jpg This could be stored in /site/assets/files/123 and showed on the page edit screen when editing page 123. Even better would be a module that logs serveral kinds of admin activity. I'd need such a module myself - so if that is what you are trying to achieve let's see if we can put something together that is reusable for everybody ?

Yes, perfect use case for RockFinder2 + RockTabulator - built exactly for situations like that. Build a custom admin page, as simple as that (https://processwire.com/talk/topic/17709-how-to-create-custom-admin-pages-aka-processmodules-yes-its-that-simple/ ) <?php // ... public function execute() { $this->headline("Demo"); $this->browserTitle("Demo"); /** @var InputfieldForm $form */ $form = $this->modules->get('InputfieldForm'); $form->add([ 'type' => 'RockTabulator', 'name' => 'yourlist', 'label' => 'Yourlist Label', ]); return $form->render(); } Set the data: <?php namespace ProcessWire; // set role that is allowed to access this tabulator $grid->access = 'your-role'; // set selector to find pages to show $selector = ['template' => 'yourtemplate']; if(!$this->user->isSuperuser()) { $selector['created_users_id'] = $this->user; } // setup finder $rf = new RockFinder2(); $rf->find($selector); // add columns to show $rf->addColumns(['title', 'foo', 'bar']); // setup grid and return it $grid->setData($rf); return $grid; Then a hook to prevent page edit of pages that where not created by the user (I think there's even a module for that) and some custom JS + PHP and you have exactly what you need. Just clone the repo at https://github.com/BernhardBaumrock/tabulator.test and see the examples ?

Here's a great step by step guide of what you have to do: https://processwire.com/docs/tutorials/hello-worlds/

Hey @adrian just doing some debugging and having a hard time finding out what's going on ? Is there a way to see the debug_backtrace easily? I mean something like the backtrace shown when an exception is thrown, but without throwing the exception and just showing the tracy in the debug bar. This could be extremely helpful in many situations. I've installed xdebug but it makes things so slow (~20s page load instead of <1s ? ). An example: In one of my modules a file is included twice instead of once. That's easy to find out via bd('fired') that will show 2 dumps in the bar. It's not so easy to find out WHY this happens and what triggered the call. When I throw an exception the trace is shown, but that's the first call. It would be nice to analyze both. It would be absolutely awesome if we could do something like trace() and get a collapsed backtrace that we can analyze step by step, click on the line of code, etc. I guess that could be helpful for everyone! Thx ?

RockFinder2 might be an option ?

My links where not meant to be solutions. Just shared my quick research. I'm happy with tracy + vscode and can't reproduce your problems ? Ever thought of switching to VSCode? *scnr ?

What exactly is the problem? ProcessWire is all about fields where you can input data in the backend and output it on the frontend. In this case you might want to use a page reference field where the user can select multiple pages (tags) and then just foreach + echo them on the frontend.

I'm not using PHPStorm, I'm using VSCode and it just works. I think I had to install this once: https://github.com/shengyou/vscode-handler This one is linked in that document: https://github.com/aik099/PhpStormProtocol And I just found this one linked there as well ? https://github.com/recca0120/laravel-tracy

Hi Teppo, thx a lot for your thoughts ? Almost ? Technically it's 2 parts: 1) The module (framework) that lives in /site/modules and provides helper functions (just like the pw admin), eg $theme->assets->render() that could render all js scripts and css styles in the head (that can be populated easily in all your templates via $theme->assets->add("assets/main.css"); $theme->assets->add("assets/main.js"); 2) The theme files that live in /site/templates/yourtheme and provide all the markup generation blocks (the basic setup is very similar to the default site profile). These files can easily be pulled from github. 3) Optional: Theme customizations, eg /site/templates/mythemechanges that only provide those files that are different from the master theme (eg a custom logo). Technically building themes is even possible at infinite recursion levels (themeMaster, themeChild1, themeChild2, themeChildN) where the first existing file is taken, starting from themeChildN (whenever it is requested as $theme->getFile("blocks/foo.php"); It's not about populating a $content variable in the theme files. It's more about providing the presentation layer (views) that can be shared across projects. The logic still has to be built into every single project, but with the huge difference that it will be as simple as that most of the time: <region pw-replace="header"> <?= $theme->render("blocks/menu.php") ?> </region> In the example above I'm just using the $content variable of the default site profile, but that just shows how flexible this approach is and that's by no means a necessity! ? In other words: In the example above I'm using the business logic of the default site profile just by including _func.php and the current template file and I'm using 2 presentation layers, first the default uikit theme (the bright one) and then the second theme with the default and secondary uikit colors. Trust me, I've been there ? ? And I disagree (but also not meant in a bad way). ProcessWire gives us the freedom to build things the way we want and that's what we all love it for, don't we? ? The problem that I see with those markup generation modules is that they are either opinionated about the output (only support one framework) or don't look good or are just not easy to use. I'm building all my sites with uikit, so it's tedious to create a menu like this: $options = [ 'active-class' => 'uk-active', 'child-item-template' => '<li {class}>{title}</li>', ... ]; $modules->get('WhatSoEver')->render($options); Why? Because I'm not clever enough to always remember the correct markup/syntax and the module has other defaults (because the module author might not use uikit) and I'm doing this waste of time (and fun) over and over again... Actually I've not done too much frontend stuff, but I try to avoid repeating work as much as possible ? But you got a valid point here and I'll think about that more closely (what should be part of themes and what should be a separate module). Well, that's a good thing as it means that we are not building the same thing twice ? But I'm still not sure about it. See the explanation about the $content variable above. Isn't that separation of concerns in the way you mean it? It would also be easy to provide a similar feature to RockThemes that calls a Controller file before it renders the template/block (or view, if you want to call it like that). Eg you could have the template file /site/templates/yourtheme/blocks/header.php <region pw-replace="header"> <div uk-grid> <div><?= $logo ?></div> <div><?= $menu ?></div> </div> </region> And then you could have a controller file /site/templates/yourtheme/blocks/headerController.php: <?php namespace ProcessWire; class headerController extends themeController { public function renderMenu() { return '<ul><li>...</li></ul>'; } public function renderLogo() { return '<a href="..."><img src="..."></a>'; } } I think I like that concept... But I have to think about it ? Same with RockThemes ? Yes, that sounds like finally we are talking the same language ? Extending themes could either be done just by replacing a content block (by just placing a file with the same name in your child theme) or - don't forget about we are still using ProcessWire ? - hooks! <?php $theme->addHookAfter("render(blocks/footer.php)", function($event) { $event->return .= "<div class='uk-text-center'>Hello World added by Hook</div>"; }); Or something like this: <?php $theme->addHook("HeaderController::renderFoo", function($event) { $event->return = 'BAR!'; }); Would be great to hear what you think about all that, thx! ? Have a great week everybody! PS: Another story that would make a lot of sense once we have some kind of standard in the frontend just like we have in the backend ($config->scripts->add(...)) would be some kind of site builder features. I've talked about that with @Jonathan Lahijani as he has put huge effort on that topic during the last year.

Hi @teppo! Thx for your elaborate answer ? Thx, this sounds like the name of my module and the headline of this topic is somewhat misleading. Actually my take is closer to WireFrame than to WordPress Themes. Or maybe it is something in between. Well. I don't like site profiles ? Actually, I hate them ? Site profiles are so rigid and one-way. What if I developed a new project, started with my great profile and implemented a new feature (like new SEO markup that was not supported yet. I'd have to implement that feature on my site, then I'd have to update my site profile if I wanted to use this feature for future projects. And then? What happens to the 10 sites that I've built using this site profile during the last year? I'd have to update all of them one by one. What I want is to implement a feature once and then just do a git pull to update all instances. Maybe I'm overengineering, though... I think our approaches are quite close. I might have only been missing the site-profile part when I played around with WireFrame. So I ended up with a blank site and thought: "Ok, that's not too much of help or not really what I wanted." The idea of RockThemes is to provide a framework on the one hand (with a helper class just like ryan has the uikit helper functions file), but in addition to that themes could also provide basic page blocks that one needs over and over again. In contrast to WordPress Themes this could be files that are completely decoupled from the site's field setup. An uikit slider for example could look like this: /site/templates/themeMaster/blocks/slider.php <?php // defaults if(!isset($images)) $images = $page->images; ?> <div class="uk-position-relative uk-visible-toggle uk-light" tabindex="-1" uk-slider> <ul class="uk-slider-items uk-child-width-1-2 uk-child-width-1-3@s uk-child-width-1-4@m"> <?php foreach($images as $image): ?> <li> <img src="<?= $image->url ?>" alt=""> <div class="uk-position-center uk-panel"><h1>Foo</h1></div> </li> <?php endforeach; ?> </ul> <a class="uk-position-center-left uk-position-small uk-hidden-hover" href="#" uk-slidenav-previous uk-slider-item="previous"></a> <a class="uk-position-center-right uk-position-small uk-hidden-hover" href="#" uk-slidenav-next uk-slider-item="next"></a> </div> This block (that can be shared across different projects and simply updated via git push/pull) could then be rendered in the theme like this: /site/templates/themeFoo/home.php <region id="main-slider"> <?= $theme->parent->render("blocks/slider.php", [ 'images' => $page->your_image_field, ]); ?> </region> This means that it would not be a problem at all if pages had different field names. I guess some of that is obsolet now? I think you also got the impression that I'm talking about WP-like themes?