d'Hinnisdaël

Release 0.6.14 fixes the overflow issue in Firefox.

1 hour ago, MoritzLost said:

On Firefox, I get a horizontal overflow in Firefox with the 'Shortcuts' panel in 'list' mode and 'small' size. Doesn't happen in Chrome.

Sure. Happy to merge your fix.

The other one seems to be an issue with the Textareas module. I hope ?

The dashboard module uses PW's internal $page->getText() method to resolve the dot syntax field name:  $page->getText($markup, false, true) (where $markup would be 'c_campaign_parameters.utm_source') Haven't worked with the textarea module so far, but it either doesn't cast strings by default or it overwrites the getText method.

Suggested fix in your case: create a custom hook property that casts the textarea field into a string manually, and then use that property for display in the dashboard panel.

2 hours ago, eydun said:

Is it possible to have the pagination show "forward" and "back" links to navigate to next 10 records?

Actual pagination buttons aren't implemented at the moment. That footer is meant to provide clarity for editors that there's more records than the ones currently displayed.

I'd consider the dashboard more a jumping-off point for editors than a replacement for other admin views better suited to browsing pages (like the page tree or listers). Ideally, they'd spend as little time as necessary on the dashboard and then go off to do whatever needs to get done in other parts of the admin.

While I'm pondering whether adding this is a good idea (it is a useful feature!), there's two options:

1. Create a copy of the included collection panel and give it a stab yourself. It shouldn't be too difficult — the module supports reloading panels via AJAX and provides the necessary JS events. Have a look at the documentation section on creating custom panels or crack open the chart panel to see an example. Let me know how it goes or if the module is missing anything to get this working.

2. There is a (currently) undocumented parameter you can supply to display a ›View All‹ button next to the pagination info. The parameter name is list and it takes a page, page ID or selector. If it's an admin page (ProcessLister), it will link to that page. If it's a content page (e.g. your Clients parent page), it will open the page tree at that page.

$panels->add([
  'panel' => 'collection',
  'title' => 'Clients',
  'data' => [
    'collection' => 'template=client, limit=10',
    'sortable' => true,
    'pagination' => true,
    'columns' => [
      'title' => 'Title',
      'url' => 'URL',
      'modified' => 'Modified',

      // Display "View All" button in footer
      'list' => 1184, // ID of lister page
    ]
  ]
]);

@Macrura My two cents on this: I feel like it's the other way around — $config as a data store is (for the most part) internal to ProcessWire's backend. The $config->scripts and $config->styles arrays are wired up in a way that makes sense for the admin panel to work properly. Using them for the frontend is surely convenient (I've done that myself on a lot of sites) but probably not meant to be used that way and prone to breaking. I've personally stopped using the internal file arrays for that reason and created namespaced versions for the frontend.

On 3/1/2020 at 9:04 AM, Sevarf2 said:

Since we are in the matter, the actions on each page, like "lock", "unpub" or "trash"... don't work, I got an alert with "undefined"

I pushed release v0.6.13 which fixes the page list action buttons (unpublish, hide, etc.)

4 hours ago, LuisM said:

Adding the panels and groups worked fine but I cant get the colors on the Pie Chart Panel to work. 
All I get is a Pie with grey segments ?

Just had a look. Your syntax for the dataset options is off: you need the remove the outer array around backgroundColor. Then it works as expected.

'data' => [
  'datasets' => [
    [
      'data' => [
        floor($normalTotal),
        floor($recurringTotal)
      ],
      'backgroundColor' => [
        'rgba(193, 66, 66, 1)',
        'rgba(193, 66, 66, 1)'
      ]
    ]
  ]
]

You're right though about the default colors not being applied to pie charts. I pushed release v0.6.12 that fixes that.

45 minutes ago, LuisM said:

Adding the panels and groups worked fine but I cant get the colors on the Pie Chart Panel to work. 
All I get is a Pie with grey segments ?

What happens if you leave out the backgroundColor key? If that restores the default color theme, it's most likely a Chart.js configuration issue — the panel only passes the options through to the library. If it's still all grey then, let me know.

4 minutes ago, Sevarf2 said:

cool...it works now, thanks. Since we are in the matter, the actions on each page, like "lock", "unpub" or "trash"... don't work, I got an alert with "undefined"

In that case, I'm afraid we're out of luck. The PageList component in ProcessWire doesn't seem to work well with multiple instances on the same page.

Do the page actions work if there's only one instance? Just to make sure I haven't broken the whole panel with the latest release.

1 hour ago, Sevarf2 said:

ehm..it shows empty lists now

Try again. I re-built the minified JS for production and pushed a new release. Should work now.

On 2/29/2020 at 12:33 AM, bernhard said:

Could you please have a look at https://github.com/BernhardBaumrock/RockDatetime and see if that might be something that find its way into the core? I think some solid date and time handling API would be a great addition to PW! RockDatetime was developed because I need it for a new module that I'm working on for dealing with date ranges. See this recent post from today about the latest additions: 

How is RockDatetime different from wrapping date fields in Carbon instances? Not trying to be dismissive here, just curious how this would help to establish a sane default for dealing with datetimes (which ProcessWire is currently lacking, unfortunately).

15 hours ago, Sevarf2 said:

there is a way to add more than 2 page-list panels? I tried but it seems ignoring the second one, it clones the content of the first one.

You're right, it was duplicating page lists. I pushed a fix as version 0.6.10. Try and pull that and let me know if it works.

5 hours ago, J_Szwarga said:

I'm attempting to use the PageIcon module to show page icons on the front end through MarkupSimpleNavigation. Although it appears PageIcon is only for backend use. Do you know of a solution to this?

Are you accessing it through $page->page_icon? That should give you the icon code.

16 minutes ago, Gadgetto said:

As SnipWire uses a lot of helper classes with common names like "Webhooks", "Taxes", "Functions", Countries", ... there is a big chance it will crash in some environments. I really don't know how to handle this currently. Implementing custom namespaces means editing nearly hundred files.

As long as your classes are named this generically, you'll sooner or later have people showing up in the forum complaining about broken sites ?

What IDE are you using? A lot of them can refactor classes and move them into different namespaces, e.g. PHPStorm has a Move Namespace dialog.

However, if you go the route suggested by teppo above, you only need to move all your helper classes into a subdirectory/namespace, setup the autoloader for that namespace, and call it a day. In reality, it will mostly simplify your code and get rid of all the require()s. I'll quote his suggestion here again:

23 hours ago, teppo said:

Just for an example, here's how I've handled this in Wireframe:

• Here's the classLoader setup: https://github.com/wireframe-framework/Wireframe/blob/6530b96/Wireframe.module.php#L297:L317
• In this case Wireframe "core classes" live in the /lib/ directory: https://github.com/wireframe-framework/Wireframe/tree/master/lib

17 minutes ago, teppo said:

Honestly: I would probably leave the module name as-is for the time being, but at some point in the (perhaps near) future add a custom namespace and declare 3.0.150 as a dependency.

That's kind of my intuition as well. Wait a little longer and see if this becomes a problem for more people, and in case rename it.

13 minutes ago, teppo said:

That's true, and one reason why historically all module files have been declared in the ProcessWire namespace – another being that most modules don't need that many classes to begin with. In cases where a module makes use of non-module classes, I would definitely recommend defining a separate (i.e. something other than ProcessWire) namespace for those ?

Am I right that in the case of Wireframe if somebody has an existing class of Wireframe in their codebase (for whatever reason), it would still clash with your module? So without waiting for 3.0.150, the class name of the module itself must be unique anyway?

Not sure how I should handle this one. Rename the module and post a notice here in the forum? Hope people will figure it out and move their own Dashboard classes into a different namespace until I can require 3.0.150? My intuition is to go with the latter, but maybe somebody has an opinion on that. When I used to cobble together custom dashboards for clients in the past, I have used ProcessDashboard or CustomDashboard. Maybe it's not that big a deal ?

Turns out using custom namespaces is only possible starting from ProcessWire v3.0.150 when this fix was implemented. I'd like to stick with the latest master release and not require the dev version, so I'll wait out the next master release. But @Gadgetto your problem might be solved by moving the traits into their own namespace.

5 hours ago, Gadgetto said:

Do you have an idea how we could solve this with the least effort?

I might be able to hack together a release later today that moves things into a different namespace — given it all works out.

5 hours ago, Gadgetto said:

Do you have an idea how we could solve this with the least effort?

Its also a general question because my module has a lot of helper classes which will collide with other modules sooner or later ...

All my module files are in namespace "ProcessWire". Is it good to use a separate namespace for my module?

I think the real culprit is this module not having a name that is unique enough — ProcessDashboard was already taken ?

The solution is probably to namespace the module itself. Mine in any case, since the name is very generic. And yours probably just to be save from future modules taking the names of your traits. Taking a look at the source of some of the larger/popular modules, most seem to be declared in the ProcessWire namespace. MarkupSitemap declares all its traits and concerns in its own namespace however. That could be interesting in your case.

9 hours ago, shogun said:

Is there a way for when I'm working locally and I create new fields or have some new CMS content updates locally, is there a way to sync up or easily push this to the cloned remote site's database without having to create a whole new backup, upload, create db all over again on the second server?

Have you tried the Migrations module? It's a bit of overhead to create migrations classes instead of using the admin UI, but it's nice to have reproducible template and field changes across all environments.

Then you'd only need to mirror or sync /sites/assets/files/ and /site/templates/ somehow.

57 minutes ago, Gadgetto said:

Yep, multi-language will require to use PW fields (at least to keep things simple). So I’ll stay with installing a cart template and a cart page where admins could add their custom cart fields. In the first version, I’ll solve this with a textarea field where the custom field config can be stored as is.

Sounds about right. Unfortunately, I've been too busy to try out the module properly and give more useful feedback ?

19 hours ago, Gadgetto said:

One idea is, that I simply add a Textarea field where an admin could enter the config string from above. SnipWire will then render this to the <script> tag.

BTW, in this case we wouldn't even need a template/page/field. I could simply add a Textarea to module config where these strings could be stored.

This might just be enough, but will this work reliably with multi-language setups?

The way I've done it in the past is by creating a repeater matrix field that has a string, an integer and a bool type for creating and editing options. But you'd have to create a field on installation and the matrix module isn't free, so I guess that's out of the question?

1 hour ago, Gadgetto said:

Taking this example from Snipcart docs ...

data-item-custom1-name="Print label"
data-item-custom1-required="true"
data-item-custom2-name="Size"
data-item-custom2-options="Small|Medium|Large"
data-item-custom2-value="Medium"
data-item-custom3-name="Gift"
data-item-custom3-options="true|false"

... this could be translated to this naming convention:

snipcart-item-c-{fieldname}-{param}

(The "c" is to avoid naming collisions with existing data-item fields)

snipcart-item-c-printlabel-name="Print label"
snipcart-item-c-printlabel-required="true"
snipcart-item-c-size-name="Size"
snipcart-item-c-size-options="Small|Medium|Large"
snipcart-item-c-size-value="Medium"
snipcart-item-c-gift-name="Gift"
snipcart-item-c-gift-options="true|false"

The n° option could be detected/added automatically by the field order within a template. But would this be flexible enough?

Are you sure that's the final markup? Whenever I had to use custom fields, the attribute names were kept as custom1, custom2, etc. So the example from the Snipcart docs are copy-paste and not meant to be changed to the fieldnames you have. It's of course possible that both work and Snipcart will detect the fields either way. Just checking.

This is an example from an existing shop I'm running:

<?php if ($cart_has_options): ?>
  data-item-custom1-name="<?= $cart_option_name ?>"
  data-item-custom1-options="<?= join('|', $cart_option_data) ?>"
  data-item-custom1-value="<?= $cart_option_value ?>"
<?php endif; ?>

17 minutes ago, Gadgetto said:

I think the best way to implement this is to let SnipWire auto-detect fields in product templates which names start with snipcart-item-custom{index} and if found add their output to markup. The admin simply needs to create those PW fields and add them to the desired product template.

I think there will be cases where custom fields will differ by product template, so the order might not be guaranteed and it's probably better to name them after their content (custom_field_size instead of custom_field_1). But how do you determine the option n° for Snipcart — if you move around the field in the template, should it keep its ID to keep order records consistent, or does that not matter as long as it's named properly?

18 minutes ago, Gadgetto said:

Implementing custom order fields will be a little bit more complex as we don't have a specific "order" template where we could attach a field. Processing a Snipcart order also won't trigger any PW page actions so where should we define a custom order field?

That's what I've done in the past: create an order template with fields that I map to custom options. Also good to have the consent text editable by site editors.

48 minutes ago, Gadgetto said:

Some of the listed features are required by SnipWire as they are essential and would require a lot of code rewrites to exclude them. So SnipWire will be changed to use v3 of the cart system when the following features are available in Snipcart:

• Inventory management
• Deferred payments
• Multi-currency

Sounds reasonable. They kind of jumped the gun for marketing reasons there; not a fan of how it was rolled out. How does a production shop even work without analytics and inventory management?

You don't happen to be in contact with them regarding ETAs on those features? I found it hard to get reliable answers even though wish I could switch my sites to their Vue cart layouts and ditch jQuery once and for all ?

1 hour ago, Gadgetto said:

The integrated SnipWire taxes provider is now even more flexible than Snipcart own integrated provider!

This looks amazing, thanks for your effort and your transparency in developing this module. Please make it very obvious how to donate or contribute to the project in whatever way is helpful ?