Jump to content

d'Hinnisdaël

Members
 View Profile  See their activity

  • Posts

    232

  • Joined

  • Last visited

  • Days Won

    9

 Content Type 

Everything posted by d'Hinnisdaël

  1. d'Hinnisdaël
    Try again. I re-built the minified JS for production and pushed a new release. Should work now.
  2. d'Hinnisdaël
    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).
  3. d'Hinnisdaël
    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.
  4. d'Hinnisdaël
    Are you accessing it through $page->page_icon? That should give you the icon code.
  5. d'Hinnisdaël
    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:
  6. d'Hinnisdaël
    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.
  7. d'Hinnisdaël
    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 ?
  8. d'Hinnisdaël
    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.
  9. d'Hinnisdaël
    I might be able to hack together a release later today that moves things into a different namespace — given it all works out.
  10. d'Hinnisdaël
    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.
  11. d'Hinnisdaël
    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.
  12. d'Hinnisdaël
    Sounds about right. Unfortunately, I've been too busy to try out the module properly and give more useful feedback ?
  13. d'Hinnisdaël
    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?
  14. d'Hinnisdaël
    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; ?>
  15. d'Hinnisdaël
    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? 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.
  16. d'Hinnisdaël
    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 ?
  17. d'Hinnisdaël
    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 ?
  18. d'Hinnisdaël
    Very nice! Love the idea. I'd like to try this out, but I think this will only make sense for production environments if the static copy is completely self-contained, i.e. including paginated pages, assets, etc. You could probably easily do that using wget and some command line magic. Your module would then make the whole process configurable and user-friendly, e.g. to run it via cron, via hook after page save, etc. Example gist: Download an entire website with wget, along with assets
  19. d'Hinnisdaël
    Seems like the _() function encodes entities only on multi-language installs. I have a working fix for this, but it's not yet on GitHub. I'll throw it in with the next release ?
  20. d'Hinnisdaël
    I'm using the standard AdminThemeFramework::getUserNavArray hook. Looks like that's a newer addition and not available on default. Any particular reason you're still using the default theme? I switched all of my client sites over to UiKit and I don't regret it. The old one looks so... old.
  21. d'Hinnisdaël
    @matjazp I added fixes for both issues you're describing. Check out the latest commit on the develop branch. These will be part of the next release.
  22. d'Hinnisdaël
    Thanks for taking the time and splitting this up ☃️ Much appreciated. I'll try this out with my next project where it'll come in really handy.
  23. d'Hinnisdaël
    @zoeck Slow day in the office — I added the editMode and viewMode options to the PageList panel as well. See the latest release. $panels->add([ 'panel' => 'page-list', 'title' => 'Information', 'data' => [ 'parent' => 'template=basic-page, name=info', 'editMode' => 'modal', 'viewMode' => 'blank', ], ]);
  24. d'Hinnisdaël
    You're right of course ? I have a custom panel that already includes the modal script, so I never noticed. I pushed a fix that should work. Thanks for debugging!
  25. d'Hinnisdaël
    Quick question: will this module work as intended if you turn off output formatting? I really like the sub-selector functionality like date.year=2019, but won't need the subfields like $page->date->year since I use Carbon for date fields in my frontend. Or are these two dependant on each other in any way?
×
×
  • Create New...