Jump to content

Gadgetto

Members
  • Content Count

    150
  • Joined

  • Last visited

  • Days Won

    4

Gadgetto last won the day on May 15

Gadgetto had the most liked content!

Community Reputation

161 Excellent

About Gadgetto

  • Rank
    Sr. Member
  • Birthday 10/05/1966

Contact Methods

  • Website URL
    http://www.bitego.com

Profile Information

  • Gender
    Male
  • Location
    Mattersburg / Austria

Recent Profile Visitors

476 profile views
  1. Just stumbled across this thread and I have a question regarding thumbnail image size in ProcessPageLister grids. I have this grid in a Process Module: What I try to do is to resize the thumbnail images in "Product Image(s)" column to 60x60px. $adminThumbOptions = $this->wire('config')->adminThumbOptions; $adminThumbOptions['gridSize'] = 60; $this->wire('config')->adminThumbOptions = $adminThumbOptions; // Instantiate ProcessPageLister with default settings $this->productsLister = $this->wire('modules')->get('ProcessPageLister'); $this->productsLister->initSelector = ''; $this->productsLister->imageFirst = true; $this->productsLister->allowBookmarks = false; ... But this doesn't work although the $config->adminThumbOptions array has the correct value for "gridSize" the thumbnails are rendered 130x130px. Any hints?
  2. I'll first need to release SnipWire and in the phase of fine-tuning I would like to move some of the functionality into separate modules. A chart module could be such a candidate. I'm gonna check out your module and see how you were thinking of implementing that. Thanks for your hint! The first separate module will be a fully configurable array/json repeater Inputfield which stores its values in a single text field.
  3. Hi Bernhard, currently integrated directly. But having this as module is a nice idea. The problem is, this thing has over 150 config parameters so packing it into a module will be quite a bit of work...
  4. UPDATE 2019-06-15 The taxes repeater field in module config editor was updated: changed to a grid view for more flexibility added field validation prepared the taxes-repeater field code to become a standalone flexible Inputfield module for general use (Array/JSON repeater input field which stores its values in a single text field) The taxes handling is completed! SnipWire now acts as a full flexible taxes-provider for Snipcart (we use Webhooks for this). No configuration needed in Snipcart dashboard. SnipCart orders are now fully working (except shipping handling). The sample shop templates got an update: customer login/logout customer dashboard link/button to view orders history and subscriptions editing of customer profile Other updates and fixes: The SnipWire Dashboard was updated (Charts, Orders, Customers, ...) --> see screenshot below. The Dashboard fetches its data from Snipcart via CURL multi - the response time for a fresh load is now under 2 seconds The Webhooks handler now supports all Snipcart events via hookable methods. Snipwire now supports all major Admin themes (Uikit, Reno and Default) All module classes/files are more structured (e.g. separate helper and service classes) Under the hood many bugs are fixed and code is updated to prevent unexpected errors. Added a crispy SVG logo for all SnipCart back-end pages 🙂 Screen-recording of updated taxes-repeater: Screenshot of SnipWire Dashboard:
  5. In Module config editor the config is saved although a field error is detected. Is this a bug or intended behavior? I'm using the ModuleConfig class in my module. Greetings, Martin
  6. Probably a bug in Reno and Default Themes. Are those older themes still supported or are they only there for legacy purpose?
  7. 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
  8. 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.
  9. 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
  10. I wanted to let you know that I am currently working on a new ProcessWire module that fully integrates the Snipcart Shopping Cart System into ProcessWire. (this is a customer project, so I had to postpone the development of my other module GroupMailer). The new module SnipWire offers full integration of the Snipcart Shopping Cart System into ProcessWire. Here are some highlights: simple setup with (optional) pre-installed templates, product fields, sample products (quasi a complete shop system to get started immediately) store dashboard with all data from the snipcart system (no change to the snipcart dashboard itself required) Integrated REST API for controlling and querying snipcart data webhooks to trigger events from Snipcart (new order, new customer, etc.) multi currency support self-defined/configurable tax rates etc. Development is already well advanced and I plan to release the module in the next 2-3 months. I'm not sure yet if this will be a "Pro" module or if it will be made available for free. I would be grateful for suggestions and hints! (please have a look at the screenshots to get an idea what I'm talking about)
  11. @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; }
  12. 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.
  13. @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 ... 😞
  14. 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?
×
×
  • Create New...