bernhard

v0.0.35 adds the file-on-demand feature. RockMigrations is now an autoload module, which makes it available as $wire->rockmigrations and makes it possible to attach hooks for several tasks. For example we could add hooks for GIT webhooks that trigger migrations after a push to a git repository... Load files on demand from remote to local development This idea comes from a blog-post of Ryan when he introduced the multiple hooks feature in 3.0.137: https://processwire.com/blog/posts/pw-3.0.137/#on-demand-mirroring-of-remote-web-server-files-to-your-dev-environment This feature is now part of RockMigrations and setup is as easy as setting a config variable: $config->filesOnDemand = "https://www.example.com";

Am I the only one seeing the page id indicator on all ProcessPageEdit pages since 3.0.173 ? I guess no, since it happens on the second instance I upgraded just now as well...

Easiest: Repeater (in the short run) Best: A custom Fieldtype/Inputfield The problem from my point of view is that either the development of the field is complicated or - if you save time on that - the following calculations and use of your setup gets complicated. I'm thinking of creating an Inputfield/Fieldtype combo for such inputs using tabulator.info... It has everything that is necessary for handling such inputs: You can add/remove/sort rows, you can show column aggregations instantly (sum of net value, sum of vat), you can show overall totals, you can even edit cell values directly (like increasing/decreasing amount of items). If you are interested in developing such a field together write me a PM ? I've created a quick and dirty demo: https://jsfiddle.net/baumrock/t70dg93b/1/

Thx, that helped. The migrate() method was intended to create pages that do not exist in the system (eg pages for a blog). I've made the setPageData method public, so if you want to set page data of the root page, use setPageData instead of migrate(): v0.0.34: https://github.com/BernhardBaumrock/RockMigrations/commit/801ac7ff94edbb7b4e430791874746580d995111

I can't answer that question - I've only (ab?)used it for listing id/path relationship of pages ?

Hi @adrian Sorry for being too briefly ? This is what I'm talking about: My module hooks into the pagehitcounter's method that logs requests to pages. I had to find a way to get the page path that relates to a given page id efficiently and easily. Otherwise I'd just have a list of page ids shown to the user (which is not really helpful) or the other option would have been to store page paths to the DB or calculate them on runtime (also not ideal). The solution I came up with is to install the PagePath module. That module creates a list of all pages that live on the system and keeps that list in sync with pages (eg when changing a pagename etc). You get a table in the DB that holds the page ID and the corresponding page path. If you don't have that module installed, there is no way (as far as I know) to get that information from the database (well, I guess that's the reason why PagePaths module exists so I'm quite confident with that assumption ? ). RockFinder has the same limitation and I've taken another approach there, see the addPath() method: https://github.com/baumrock/rockfinder3#addpath Does that clarify things? ?

Could you please provide a reproducable code snippet that I can use on a fresh PW installation having RockMigrations installed? $rm = $modules->get('RockMigrations'); $rm-> ... your code here ... And maybe add what you are trying to achieve.

I'm talking about the code of the migration that throws the error - not the code of your fix ?

Thx for finding that. Could you please share your code that you are using so that I can easily reproduce it?

I've done something similar on my extension module for PageHitCounter where only page IDs of page hits are stored. You need to enable PagePath module and then you can join page paths to page ids easily and efficiently. The page paths are kept in sync by the module, cached in the DB and therefore do not need to be "calculated" at runtime on every item.

Another showcase ? $this->addHook('/rockgrid2/(.*)', function($event) { $name = trim($event->arguments(1),"/"); $grid = $this->getGrid($name); if(!$grid) throw new Wire404Exception("Grid not found"); if($event->config->ajax) $grid->json(); // send json and die() return $grid->debug(); }); When requested via AJAX you get gzipped json (as source for a tabulator grid), when requested in the browser you get a sortable+filterable grid of your data ? And tracy is always waiting for bd() calls for quick and easy debugging ?

? ? ? ? ? What a great addition!! Thank you Ryan!! ?

Thx RobinS for the idea about the getExtraMarkup hook! I slightly changed your version: $this->addHookBefore('AdminTheme::getExtraMarkup', function (HookEvent $event) { $config = $this->wire->config; $url = $config->urls($this); $config->scripts->add($url."lib/moment.min.js"); $config->scripts->add($url."tabulator/js/tabulator.min.js"); $config->scripts->add($url."Grid.js"); $config->scripts->add($url."RockGrid2.js"); $config->styles->add($url."tabulator/css/tabulator.min.css"); }); using the "before" hook makes it possible to use the config->scripts|styles->add syntax ? I'd love to get a $config->scripts->addAfter("/my/script.js", "/my/other/script.js") feature - but acutually I've always found a way to get the correct order by using proper hooks...

Maybe someone that is better on the JS/CSS side than I am can come up with a good solution then ?

RockCalculator Add a calculator to any Inputfield in the ProcessWire backend. Setup At the moment there is no UI for defining fields that should support the calculator. You have multiple options: Tracy Console // show rockcalculator and round result to .00 $field = $fields->get('yourfieldname'); $field->set('rockcalculator', 2); // 2 digit precision $field->save(); RockMigrations $rm->setFieldData('yourfield', ['rockcalculator' => 2]); Hook buildForm $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->return; $page = $event->process->getPage(); // edited page if($page->template !== 'yourpagetemplate') return; if($f = $form->get('yourfield1')) $f->rockcalculator = 2; if($f = $form->get('yourfield2')) $f->rockcalculator = 2; if($f = $form->get('yourfield3')) $f->rockcalculator = 2; }); Github: https://github.com/baumrock/RockCalculator Modules directory: https://processwire.com/modules/rock-calculator/

Seeing that example it might make more sense to add different options to pw-panel: One showing the panel on top of the background and one pushing the main page to the side while keeping everything visible. That would also make it possible to support mobile devices... If anybody has time, feel free to improve the module ? ? Also if we have any JavaScript experts - I'd love to have the Iframe configurable in its width via mouse drag... no idea how that could be done. At the moment it is set to 40vw.

Glad it helps! That's already possible - I've added an example to the readme: $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $page = $event->process->getPage(); if($page->template !== 'mypagetemplate') return; /** @var RockIframe $iframe */ $iframe = $this->wire->modules->get('RockIframe'); if($iframe) $iframe->show("http://www.example.com"); });

Long time no module ? Github: https://github.com/baumrock/RockIframe Modules Directory: https://processwire.com/modules/rock-iframe/ Problem Sometimes the editor wants to see a preview of a file while editing a page. For example this can be helpful when digitizing invoices. Regular ProcessWire panels can be used for preview but overlap the page editor so the user has to open and close the panel repeatedly while working. RockIframe shows a preview of any content that can be rendered in an iframe and keeps the page editor 100% visible to the user. Usage Simply call $modules->get('RockIframe')->show('path/to/your/file.pdf') anywhere in the admin to show your data in a sidebar iframe on page load. You can also define a Pagefile(s) object as source of the iframe. Example This example shows the first file of the field myfilesfield on the page edit screen of pages having template mypagetemplate: $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $page = $event->process->getPage(); if($page->template !== 'mypagetemplate') return; /** @var RockIframe $iframe */ $iframe = $this->wire->modules->get('RockIframe'); if($iframe) $iframe->show($page->get('myfilesfield')); }); Ideas & Notes PDF preview relies on the browser's capability to preview PDFs. Also at the moment there are no checks which content is thrown to the iframe as source. For images for example we could use https://leafletjs.com/examples/crs-simple/crs-simple.html to enable panning & zooming on the image. For better browsersupport of PDF we could use https://mozilla.github.io/pdf.js/web/viewer.html;

Thx @snobjorn for creating the issue https://github.com/processwire/processwire-issues/issues/1339 Everybody having this problem please give it a thumbs up! I'm locked to v171 due to this issue ?

Sorry, I don't get what you mean by "programmatically" and I don't get your example. Maybe others can help ?

Thx @Gadgetto my message was not meant as criticism. I just don't get WHY SnipWire does all that. Ok, I get that you need to setup some fields that hold necessary data (vat, description, image) and then you need to create the markup. That should be quite simple though without using SnipWire (for example using RockMigrations which you can guess I'm using in every project ? ). The cart-button could then look somewhat like this: <button class="snipcart-add-item uk-button uk-button-primary" title="Add to cart" aria-label="Add item to cart" data-item-name="<?= $page->title ?>" data-item-id="<?= $page->id ?>" data-item-price='<?= $page->price ?>' data-item-url="<?= $page->httpUrl ?>" data-item-description="<?= $page->description ?>" ...> <span uk-icon="icon: cart"></span> Add to cart </button> Ok... I get that's quite tedious and having a helper method for that could for sure be handy. What I still don't get is why you took all that effort to get all (or at least many?) of the features of snipcart into the pw backend? Wouldn't it be a lot easier if the clients just managed their snipcart shop via the snipcart website? As far as I understood the client has to register an account there and then gets a login where he/she can manage their products/sold items etc? It's obvious that SnipWire can do a lot and I'm quite impressed - I'm just not getting the WHY behind all that. Maybe it's just because I don't know anything of the PAIN you are solving because I've never setup a snipcart store manually...

Hi Tobias, welcome to the forum! Sorry, I have no answer for you, but I can just tell you that I've never had any problems using $page->trash() in any of my projects. So your tricky part should really not be tricky at all ? Maybe there's something else going on...

Could anybody having experience with this module please explain what the module EXACTLY does? I don't really get it from the description. And SnipCart itself claims this: As I understood it's as simple as adding custom button markup to the site and you are up and running your snipcart site. The dashboard in this case would obviously be hosted at snipcart and not inside my processwire project, but is that the only reason for this module? I have the feeling that I must be missing something ? Thx for your insights! As far as I understood I don't need SnipWire for that?! Well... what exactly takes time if I am NOT using SnipWire? Isn't it just adding snipcart buttons? Which link is missing? I thought the missing link were just some data-attributes? <button class="snipcart-add-item" data-item-id="starry-night" data-item-price="79.99" data-item-url="/paintings/starry-night" data-item-description="High-quality replica of The Starry Night by the Dutch post-impressionist painter Vincent van Gogh." data-item-image="/assets/images/starry-night.jpg" data-item-name="The Starry Night"> Add to cart </button> https://docs.snipcart.com/v3/setup/products

I don't understand your question. Examples are always a good idea ?

PRs to the readme always welcome! Agreed. I've mentioned that I'd vote for an API first approach. Build UI for beginners, but building it upon a solid API (something similar to RockMigrations) so that experts can just as easily (or even easier) use that tools for automation or advanced needs. PW goes that route very often. I hope that one day migrations adopt that approach as well.