bernhard

Just paste the content of your _main.php file and your ##yourtemplatename##.php file and we can show you what to do 😉

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.