Jump to content

bernhard

Members
  • Posts

    5,759
  • Joined

  • Last visited

  • Days Won

    273

Everything posted by bernhard

  1. Yes. That were 2 different questions, the more interesting being WHY you want to use AJAX for site navigation ?
  2. Could you please tell us WHY you are using this AJAX technique? ? Do you know https://barba.js.org/index.html ?
  3. Maybe you think they are NULL but they actually are not ? How do you check the values? I recommend using TracyDebugger and doing bd($input->get('yourvar')) to check properly.
  4. Just paste the content of your _main.php file and your ##yourtemplatename##.php file and we can show you what to do ?
  5. 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
  6. 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 ?
  7. 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!
  8. 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? ?
  9. 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 ?
  10. 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.
  11. 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:
  12. $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?
  13. They CAN certainly do. But it's not plug&play, it will need some more or less simple coding ?
  14. 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.
  15. I don't see a problem and that's exactly how ProcessWire itself does it...
  16. 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 ?
  17. 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.
  18. 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 ?
  19. 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 ?
  20. Here's a great step by step guide of what you have to do: https://processwire.com/docs/tutorials/hello-worlds/
  21. 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 ?
×
×
  • Create New...