Gadgetto

Hi there, I have a simple Fieldset layout in a process module based on the code below: /** @var InputfieldWrapper $wrapper */ $wrapper = new InputfieldWrapper(); /** @var InputfieldFieldset $fsTop */ $fsTop = $modules->get('InputfieldFieldset'); $fsTop->icon = 'bar-chart'; $fsTop->label = $this->_('Top Store Actions'); $fsTop->wrapClass = 'bottomSpace'; /** @var InputfieldMarkup $f */ $f = $modules->get('InputfieldMarkup'); $f->label = $this->_('Top Customers'); $f->value = $this->_renderTableCustomers($dashboard[SnipRest::resourcePathCustomers]); $f->columnWidth = 50; $f->collapsed = Inputfield::collapsedNever; $fsTop->add($f); /** @var InputfieldMarkup $f */ $f = $modules->get('InputfieldMarkup'); $f->label = $this->_('Top Products'); $f->value = $this->_renderTableProducts($dashboard[SnipRest::resourcePathProducts]); $f->columnWidth = 50; $f->collapsed = Inputfield::collapsedNever; $fsTop->add($f); $wrapper->add($fsTop); $out .= $wrapper->render(); In UIKit admin theme it renders correctly like this: In Default and Reno theme like this (which is wrong): If I change the InputfieldWrapper to InputfieldForm it works as expected. But I don't like to use a form wrapper because the fields don't represent a form and they don't have any input. What am I doing wrong? Greetings, Martin

ANOTHER UPDATE SnipWires Taxes (VAT) configurator is ready! I added a new custom Fieldtype FieldtypeSnipWireTaxSelector based on an idea of @BitPoet - thanks for that! Also I created a full featured repeater for module config editor including drag&drop handling. Have a look at the animated GIF below. The taxes you configure here will be available as select option list in product page editor. The first tax in the configured list will be used a s the default tax in the custom field.

UPDATE OK, after I've faced that for and against again, I've decided to make the module freely available. If you are interested, you can test the current state of development. I already put the module on GitHub. Please note that the software is not yet intended for use in a production system. (Alpha version). For example, the configuration and handling of the VAT rates are still missing. Also the dashboard is still incomplete. And many other things needs to be improved and implemented... ? If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests. https://github.com/gadgetto/SnipWire

Done! ?

SnipWire - Snipcart integration for ProcessWire Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire. With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required. SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development: Status update links (inside this thread) for SnipWire development 2020-07-03 -- SnipWire 0.8.7 (beta) released! Fixes some small bugs and adds an indicator for TEST mode 2020-04-06 -- SnipWire 0.8.6 (beta) released! Adds support for Snipcart subscriptions and also fixes some problems 2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website ---- INITIAL POST FROM 2019-05-25 ----

@Macrura I just stumbled across this interesting older post. Since I'm currently working on a module that accesses an external REST API, the topic of caching is very interesting. I use WireCache to cache the REST queries and am currently working on improving performance. I stumbled across preloadFor. Does anybody have a code example which shows how preloadFor can/should be used to improve performance? This is a sample how I'm currently using WireCache: public function getSettings($key = '', $expires = WireCache::expireNever, $forceRefresh = false) { if (!$this->getHeaders()) { $this->error($this->noticesText['error_no_headers']); return false; } if ($forceRefresh) $this->wire('cache')->deleteFor('SnipWire', self::cacheNameSettings); // Try to get settings array from cache first $response = $this->wire('cache')->getFor('SnipWire', self::cacheNameSettings, $expires, function() { return $this->getJSON(self::apiEndpoint . self::resourcePathSettingsGeneral); }); return ($key && isset($response[$key])) ? $response[$key] : $response; }

That's what I'm doing currently. I thought there should be a more elegant way. If I try to access a module property via $this->my_property ProcessWire should decide whether the value comes from the database (if available) or from the defaults.

@horst This makes sense. I'm using the MyModuleConfig.php Class method to handle module configuration. If accessing module config via $modules->getConfig('MyModule') I only get config from db. If module configuration settings aren't at least saved once I get the following results: $this->config_key --> 'DEFAULT VALUE' $data['config_key'] --> null (key doesn't exists) @ryan says in his blog post regarding "ProcessWire 2.5.5 – New module configuration" https://processwire.com/blog/posts/new-module-configuration-options/ I thought this should be handled automatically? Where is the best place in MyModuleConfig.php Class to merge defaults with db values? In constructor? Think I still don't understand module config behavior fully ... ?

Hi, while working on 2 new configurable modules (with a lot of config settings) I encountered that the module config is not created/saved to db when the module is installed. You need to hit save to write the default config to database. This is a problem if I need some of these config values at modules runtime. Wouldn't it be better to save the default config values of the module on module install? Do I miss something here?

Just implemented your solution and it works perfectly!

@bernhard this is great! I already tried it with a hook before field render, but the problem was, it was always set to checked even when unchecked by user. I didn't know the setAndSave method.

@bernhard I know how to set a value to an InputfieldCheckox but my problem is, I create a Field type=InputfieldCheckbox via API and assign it to a template. If a user creates a new page with this template, the checkbox should be checked by default.

@ryan how can this be done while creating a field on API side? I tried "defaultValue = 1" property, but didn't work.

Also from me a +1 for Checkbox checked by default property. I just need to set a "taxable" flag to true by default in an e-commerce module. Otherwise the store owner would need to go and check this checkbox for most products (only some of the products will not be taxable).

Thanks @bernhard!

Hi, I'm just experimenting with Markup Regions and have a question regarding conditional replacement of a region. Is this the right way to do the following: <?php if (!modules()->isInstalled('ModuleRequiredForRendering')) { ?> <div id="content"> <strong>ModuleRequiredForRendering</strong> module is not installed. Module is required to render this page! </div> <?php return; } ?> <div id="content"> // output content ... </div>

Ok, thanks! Solved it like this: /** * Get all templates except system templates (name => label) * * @return WireArray $templates * */ public function getTemplates() { $templates = new WireArray(); foreach ($this->wire('templates') as $t) { if (!($t->flags & Template::flagSystem)) { $templates->add($t); } } return $templates; }

Sorry, just stumbled across that older post searching for an answer regarding templates selectors... I'm looking for a method to select all templates except system templates. This part from your code above doesn't work here: $templates->find("flags!={template::flagSystem}") it could only get it to work like this: $templates->find('flags!=' . Template::flagSystem) But what's more important is: "flags" is a bitmask value, is it OK to simply compare it in a selector?

Hi @kongondo, I'm also using Intelephense and the only thing I added to my VSCode settings is this: "files.associations": { "*.module": "php" },

Thank you for your kind words!:-)

GroupMailer needs a lot of meta data like some send counters, status-flags, send/finished dates and so on - all meta fields are hidden fields only and not editable by the user. The custom Fieldtype I created has all these columns packed in one field. Using FieldtypeFieldsetPage would mean that I create separate fields for each of these meta columns (if I understand right). Wouldn't this have a performance impact. Instead of using a single (multi-column) field I'd need to use many separate fields.

I need to have a look at this Fieldtype and how this is implemented. I currently don't fully understand how this is meant to be used.

@LostKobrakai FieldtypeFieldsetPage looks great - didn't even know this exists! Thanks for this hint! Using a template for configuring/defining a GroupMailer message page was my initial intention. But wouldn't that be too inflexible? Wouldn't it be better if the dev could use any template he likes just by adding a single field? It would also allow to "convert" any existing page to a GroupMailer Message on the fly. I'd like to hold the Module as flexible as possible but also easy to setup. The longer I work on the project, the more uncertain I will be about the implementation...

You are right! Each message is a unique page. To be flexible, I decided not to use the title field as email subject. GroupMailer will be designed so that each page can be a message. It will only be necessary to add a custom field (FieldtypeMessageMeta) to the corresponding template. This field type will include the subject field. So it is possible that pages have separate titles and email subject.

I also think so. So I'll let the field be single-language for now and if there are requests to add multilingual feature it can be added later.