bernhard

This error is fixed in v0.0.3 ? The reason was simply that RockFinder2 is autoload=admin, so on the frontend you need to do $modules->get('RockFinder2') before any new RockFinder2() statements.

Can we see the code of your module? This is an example I am using: class ProcessEARDashboard extends Process { public static function getModuleInfo() { return [ 'title' => 'EAR Dashboard', 'version' => '0.0.1', 'summary' => 'EAR Dashboard', 'icon' => 'gears', 'requires' => [], 'installs' => [ 'ProcessEARNew', 'ProcessEARImport', ], 'permission' => 'ear-dashboard', 'permissions' => ['ear-dashboard' => 'May see the EAR dashboard'], 'page' => [ 'name' => 'ear', 'title' => 'EAR Dashboard' ], ]; }

Thx for the typo ? Sorry, just had a look and I think it would be a lot easier for you to implement such a feature than anybody else because we don't know exactly how things work and play together (unless diving into the almost 500 lines of code...).

Thx for finding this! v0.0.5 fixes that ? I was also not sure about rounding the tax... I changed it to be 5 digit precision always. Calculations now always depend on NET and TAX solely. Gross is calculated not via ( net * (1+(net*tax)) ) but simply ( net + vat ). This should eliminate any rounding issues as it will always be GROSS = NET + VAT Thx @tpr I added a test in v0.0.7 - really great module! Though I think it could be made a lot easier for module developers to use your module (which would hopefully increase the change of more modules adding tests to their repos!): At the moment there is a lot one has to do when one wants to add a test to thier module: Install your module (obviously), then create an admin page, set the process, set the filepath, create the test. IMHO this could (should!) be simplified to this: Install your module Add a hook in my module Add a test in my module The hook could look like this: $this->addHookAfter("ProcessNetteTester::getTestDirectories", function($event) { $dirs = $event->return; $dirs[] = $this->config->paths($this)."tests/"; $event->return = $dirs; }); So this would add the path "/var/www/foo/site/modules/FooModule/tests/" to the scanned directories. ProcessNetteTester would then know to scan this folder for tests and list it under a json dropdown just like the db backups module: So the entry "RockPriceTests" would be "Nette Tests" (which could be automatically created on install of ProcessNetteTester) and then list all tests as submenu (like RockPrice). Hope that makes sense! Would be great to get support for this and I'm quite sure many would use it (as it is really not difficult to get started with nette testing framework) ?

Thx for that input. To be honest: No. I have no experience with unit testing at all. It's on my list for a long time, but haven't found the time to get into it yet. But even without tests I think that this module makes the situation already a lot better compared to the way I (and maybe others) have been doing it: Creating several different fields and maybe doing custom JS logic in some additional hacky file... As you obviously have some experience with this it would be great if you could provide some step by step walkthrough what it needs to get started with your module and how I would include tests into my module (or in general every module developer). I read the docs, but it's still not obvious how I'd apply these tools to my module and which cases I'd write tests for (and how). And how would I test for javascript related features like the input pasting one that I mentioned above?

Yeah, I didn't find it in that data, that's why I asked ? That would be a step forward, but not enough. I've looked into the core code how things are defined... Most methods look like this: public function ___saveReady(Page $page) { And the snippet output should be this: $this->addHookAfter('Pages::saveReady', function(HookEvent $event) { $pages = $event->object; /** @var Pages $pages */ $page = $event->arguments(0); /** @var Page $page */ }); The important part is the typehint @var Page $page (all necessary info for $event->object is already there). In this case this information is already present in the hook definition: We know that the first argument is of type Page and its name is $page. That could then be transformed into a snippet. Unfortunately there are also cases where the parameter type is only declared in the phpdoc. If that is a lot more complicated I'd be fine with not supporting these cases ? It's a helper tool where it would be absolutely fine that it works in some cases but not in all. Where it does not work we'd have to do what we now do all the time: Write code on our own ^^ I have almost no idea how your api parser works, so I hope I'm not asking for too much here. It's nothing really important, but on the other hand it could maybe be really helpful...

This is a very early realease and at the moment more of a proof of concept that needs some more work (not a lot though!). Currently it adds VSCode snippets for all hookable methods and adds proper variable type declarations so that we get intellisense automatically: This module was easy to build thx to @adrian's work on TracyDebugger (Tracy is a dependency for the module). What I'm missing at the moment and where @adrian could hopefully provide some help: I'd like to list the arguments of the hookable method automatically. As you can see in the screencast I have to type $event->arguments(0) manually all the time. Does tracy's api explorer know something about the used arguments? If yes it would be trivial to add this to the snippets generator ? PS: It adds two versions of all hooks: One regular hook that adds a separate function and one inline hook that does the same inline (as shown in the GIF). PPS: Currently the module does build the snippets file automatically only if it does not exist. It would be great if the module recreated the file whenever the api changed. @adrian any hints what the easiest way would be to achieve that? https://github.com/BernhardBaumrock/RockHookSnippets

v0.0.5 fixes a little glitch with the defaultTax setting ? I've just discovered one problem with my inputfield, though: I can't input wrong calculated invoices (.62 net + .32 vat = .94 gross, not .95 like in the invoice!) ? -->

That's the old version of https://processwire.com/api/ref/wire-text-tools/populate-placeholders/ and it does what it says: Populate placeholders in a string with corresponding variables (thx for reminding me about that! ? ).

Thx ? v0.0.4 makes it possible to paste numbers in different formats: https://github.com/BernhardBaumrock/RockPrice/commit/74d496320de2c4e0c077fa290dadbdadff932af5 I'm using HTML input type number for the inputs. That has the benefit that the formatting is consistent across all fields. But I just realized today that pasting "1.234,00" was not possible because for the field this was not a valid number. My implementation now only keeps the last dot of the number and makes that dot be a dot (not a comma). 5.432,00 --> 5432.00 1.234.567,00 --> 1234567.00 1,234,567.00 --> 1234567.00 1.000 --> 1.000 (which leads to an input of ONE instead of one thousand) The last one is a drawback, but I guess it's unlikely to have such inputs. I could also remove those separators if the remaining digits are larger than 2 1.000 --> 1000 1.00 --> 1.00 1.0 --> 1 Any opinions? What works great already is that pasting does also strip off all non-digit chars. So you can just copy & paste things like this: USD 1200.00 1.200,00€ 4,60 EUR Finally doing my own accounting starts getting fun ?

v0.0.3 adds user templates to restore complicated recurring prices (I was too lazy to always input the same complicated numbers for my internet invoice ? ) User templates You can save custom user templates to easily restore complicated recurring pricings:

Turns out that things were not as easy as I first thought ? After the input of several invoices I came to a case I didn't think of (or didn't want to think of): Having multiple different tax values for one invoice ? I totally refactored the module and the result does have more features and is also a lot nicer from the code. The field's value is now always a RockPriceMulti object that can hold any number of RockPrice objects. v0.0.2 - Initial post is updated!

I've also had those problems, I know that it's not really straight forward and limiting sometimes... At the moment I have this in place and need to test it over the next weeks ? $this->addHookBefore('ProcessPageList::execute', $this, 'redirectPageList'); /** * Redirect all PageList requests to Dashboard */ public function redirectPageList(HookEvent $event) { if($this->config->ajax) return; if($this->page->id > 3) return; $this->session->redirect($this->pages->get('name=ear')->url); } Edit: Just added the page id check, then all requests to "pages" will be redirected but one can show the pagelist by going to "pages > tree" ? I try to answer that by asking you a question ? I have several custom Process Modules. They are great, because I can control where they live (menu) and who can see them (access control). How would I display one of your - I say it again - really nice looking dashboard panels in one of my modules? I've just added a commit to my example module: https://github.com/BernhardBaumrock/InputfieldChartDemo/commit/3efa4bd8355bfe6e7499254cad58e70d3f283147 IMHO this is really close to what you built on your dashboard (at least as far as I understood it until now), but it uses PW core features and only a little extra markup: https://github.com/BernhardBaumrock/InputfieldChartDemo/blob/3efa4bd8355bfe6e7499254cad58e70d3f283147/ProcessInputfieldChartDemo.module.php#L139-L146 I agree that it is not the nicest thing to layout pages using InputfieldForm elements, but I think it would be the better way to push PW in that regard than creating custom solutions. We all know the benefits of using existing components: showIf would work out of the box collapsing works out of the box (ajax loading fields) development is the same for dashboard panels and regular inputfields panels can be used everywhere styling applies automatically (imagine a custom admin theme using your dashboard panel... To name just a few ? What I mean is for example we could have something like InputfieldGrid that could work like this: $grid = $modules->get('InputfieldGrid'); $grid->addColumn([ 'class' => 'uk-width-1-4@m', 'children' => [ [ 'type' => 'markup', 'label' => 'one foo', 'value' => 'one bar', ],[ 'type' => 'markup', 'label' => 'one foo', 'value' => 'one bar', ], ], ]); $grid->addColumn([ 'class' => 'uk-width-3-4@m', 'children' => [ [ 'type' => 'markup', 'label' => 'two foo', 'value' => 'two bar', ],[ 'type' => 'markup', 'label' => 'two foo', 'value' => 'two bar', ], ], ]); $grid->render(); That would be really easy to build and could - same as everything else - also be used on page edit screens etc. Scenario from todays work: I'm building a custom CRM for myself where I manage invoices and documents. After import they get flagged as TODO. Then I see them on the Dashboard: When editing one of those pages I have basically the same Inputfield showing a list of all other todos:

Hi @d'Hinnisdaël First of all congrats to this beautiful module. I have some suggestions and remarks: The panels do not have proper dependencies set. All panels are installable (and throw an exception, when installed): IMHO the Dashboard master module should be the only installable module. https://philippdaun.github.io/processwire-dashboard/#/configuration?id=dashboard-as-entry-point Any reason why you chose this version over a module setting (eg checkbox) that adds a hook? I was hoping that your way of doing it would solve the problem that when clicking "Save & Exit" one would be redirected to the dashboard. But still one gets to the page tree. This also happens when trashing a page. This is one thing annoying me for a long time, but I didn't try to find a solution for it yet. Maybe you can have a look, because imho when having a dashboard it's more likely that one wants to see the dashboard than the page tree ? Edit: Just saw that changing the main admin page's process does at least help after trashing pages ? I think I'll also redirect all user requests from the page tree to the dashboard... DashboardPanelChart uses jsdelivr CDN to load chart.js - this means that the panel will not work on offline applications (intranet). I think it would be better to ship chartjs with the module. This brings me to the next and more important point: Have you thought of making panels Inputfields? The last point needs some more words ? I really wonder (not to say dislike) why you made the dasboard work on your own panel implementations rather than using regular PW Inputfields. Please don't take this as devaluation of your module, but after all it's just a ProcessModule like all the other admin pages (just really looking a lot better!). I've created a very simple Inputfield and posted a thread in the tutorials section: Take this screenshot of the Grid Dashboard demo: This is VERY similar to your Dashboard module - with the big difference that it is based on PW Inputfields that can be used everywhere in the PW ecosystem! Your panels can not. As I said your module does indeed look a lot better than a regular PW form. For example as far as I know grid spacing is not possible using InputfieldFieldset. Also the admin width settings are somewhat limited (see this old issue on github). But this is my point: Instead of creating a new module that handles things in its own ways it would be a lot better to improve or extend the PW internal tools. This means we could either create nicer CSS for PW Inputfields (here the InputfieldFieldset) or we could create an Inputfield that wraps other inputfields in a Uikit grid (as Uikit is already on board). This approach would also make it possible to use the "panels" that you create for your dashboard in other places like PW page edit screens or in other ProcessModules. I really like the look & feel of your panels, so it would be great to be able to use them all over the PW backend and not only in your module! Thx for creating and sharing this - I hope you get my point and I'm looking forward to hearing what you think about converting panels to Inputfields ?

During testing of the https://processwire.com/talk/topic/22847-processwire-dashboard/ module I've created this simple demo inputfield to show how Inputfields can be used as presentation blocks in ProcessModules. The result is this little inputfield that shows the getting started chart of chartjs: https://www.chartjs.org/docs/latest/ https://github.com/BernhardBaumrock/InputfieldChartDemo It comes with 2 ProcessModules 1) One single chart inputfield 2) Grid Demo Creating an Inputfield is really nothing more than creating a module file having 3 methods: <?php namespace ProcessWire; class InputfieldChartDemo extends InputfieldMarkup { public static function getModuleInfo() { ... } public function ___render() { ... } public function ___processInput($input) { return false; } } Place this in /site/modules/YourModuleName, name the class exactly the same as your folder and you get an installable Inputfield that you can use everywhere in your admin and share across projects! Creating a ProcessModule is also very simple (see this old post): You do even need only 2 methods in this module! <?php namespace ProcessWire; class ProcessInputfieldChartDemo extends Process { public static function getModuleInfo() { ... } public function execute() { ... } } Using these internal tools it is really easy to create totally tailored user experiences for your clients in the PW backend!

This sounds great, even though I don't use trello ? A short screencast would be great to get a quick impression ?

Don't know if anything changed since 2017 and just found this post by coincidence but wanted to show how this can be done easily now in 2020 ? $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function(HookEvent $event) { $actions = $event->return; $actions[] = [ 'value' => 'foo', 'icon' => 'check', 'label' => 'foo', ]; $event->return = $actions; }); The value of the clicked submit action is stored in $input->post->_after_submit_action (you can hook Pages::saved or ProcessPageEdit::processInput)

v1.0.10 is out: pwhookargument: Get hook argument pwhookobject: Get hook object

Found the solution ? /** * Modify submit button on doc-import pages */ $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function(HookEvent $event) { $page = $this->pages->get($this->input->get('id')); if(!$page->id OR !$page->template == 'docimport') return; $event->return = []; }); $wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event) { $form = $event->arguments(0); $page = $this->pages->get($this->input->get('id')); if(!$page->id OR !$page->template == 'docimport') return; $s = $form->getChildByName('submit_save'); $s->value = 'Import starten'; $s->icon = 'download'; }); ? Does anybody know how I can remove the dropdown items from the page edit submit_save button? As I didn't find a solution quickly I wanted to replace the button entirely, but this results in the following markup: $wire->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { $form = $event->arguments(0); /** @var InputfieldForm $form */ $s = $form->getChildByName('submit_save'); /** @var InputfieldSubmit $s */ $form->remove($s); }); This hook results in this output: I could hide this markup via CSS but I'd prefer a clean solution ? Thx!

--- There might be some changes to this module in the near future! Please see this comment --- I guess we have all been there... We need to store a price to a product. "Ok, easy, let's create a new field for that in the PW backend!" might be the first thought. But then the headache starts... What about TAX? What about NET and GROSS values? And what about rounding problems when not using the correct float or decimal values ( https://processwire.com/talk/topic/7542-development-fieldtypefloat-fieldtypedecimal/ )? Meet RockPrice - a brand new (and not well tested!) module to save you from those headaches and make the UI more compact and reactive (nobody wants to calc tax/net/gross manually!). If you discover any issues or have suggestions for improvement please let me know! ? --- Download: https://github.com/BernhardBaumrock/RockPrice --- RockPrice Price Fieldtype + Inputfield for ProcessWire CMS Settings Usage The field always returns a RockPriceMulti object. This object contains an array of items and the totals vor vat, net and gross (where tax stands for the tax rate in percent and vat for the actual tax value, eg. Euros or Dollars): d($page->price); d($page->price->items->first()); API Saving field value: $page->setAndSave('price', [1000, 20]); $page->setAndSave('price', [ [1000, 20], [3000, 10], ]); Comparisons $p1 = new RockPrice(1000, 20); $p2 = new RockPrice(1000, 10); d($p1->equals($p2)); // false $m1 = new RockPriceMulti([$p1, $p2]); $m2 = new RockPriceMulti([$p1, $p2]); $m3 = new RockPriceMulti([$p2, $p1]); // flipped! d($m1->equals($m2)); // true d($m1->equals($m3)); // false d($m1->equals($m3, true)); // true (ignoring sort order)

Unfortunately yes ?

Hi @Sevarf2 Maybe, but I don't use it any more on any installs. I'm using RockMigrations on all my sites and TracyDebugger makes it absolutely trivial to get the information necessary ?

@Pixrael thanks for the insights! Do you have any links for live examples using PW + Shopify? ?

Every Inputfield consists of this markup: <li class="Inputfield"> <label class="InputfieldHeader"></label> <div class="InputfieldContent ..."></div> </li> I want to inject some code either at the top or at the bottom: Hooking Inputfield::render does only let me modify the inner markup of InputfieldContent. Am I missing any hooks or other magic? ?

Hm. My experience with foxy was quite bad. It looks ugly imho (both the backend and their frontend shop implementation), the checkout is complicated to impossible to customize and the implementation was not that straightforward. Luckily I don't have any e-commerce projects on the radar, but this module might be worth a try: