Jump to content

Recommended Posts

25 minutes ago, matjazp said:

Some encoding problems, this is how it looks when dashboard is empty:

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 🔮

  • Like 2

Share this post


Link to post
Share on other sites

Oh wow, I've just been putting together my own custom dashboard module for a client but this might save me a lot of work!

Share this post


Link to post
Share on other sites

Hi @d'Hinnisdaël,

I just installed your module (via "Add Module From URL") but immediately get an exception after hitting download:

Compile error
Cannot declare class ProcessWire\Dashboard, because the name is already in use

I also found the culprit: It's a PHP trait within my module which has the same name as your module class. I'm using PHP traits to split large process modules into smaller parts. Didn't know that traits are treated like class files in namespace.

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?

870809573_Bildschirmfoto2020-01-31um08_45_52.thumb.png.95a9efadcc1fd5fcbd53d0c6971b465c.png

<?php namespace ProcessWire;

trait Dashboard {
    /**
     * The SnipWire Dashboard page.
     *
     * @return page markup
     *
     */
    public function ___execute() {
        $modules = $this->wire('modules');
        $user = $this->wire('user');
        $config = $this->wire('config');
        $input = $this->wire('input');
        $sniprest = $this->wire('sniprest');

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I was also slightly concerned about this module using such a generic module class. I also have a module Dashboard, but i use the Process prefix, as well as sometimes a suffix, so i now use ProcessDashboards (because my module allows for unlimited dashboards), or something like ProcessDashboardRedux; I like how @bernhard uses a custom element in his modules (Rock..) which also ensures uniqueness...

Share this post


Link to post
Share on other sites
3 hours ago, d'Hinnisdaël said:

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.

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 🙂

(This part is also well supported, so no need to wait for 3.0.150.)

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

While namespaces are often enough to tackle the issue of clashing traits and classes, it's also a common recommendation for traits and interfaces to be named differently: SomeNameTrait, SomeNameInterface, etc. PSR also recommends (or requires, really) this approach.

  • Like 2

Share this post


Link to post
Share on other sites
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 🏓

Share this post


Link to post
Share on other sites

As the module is quite new, renaming the module in this stage wouldn't be a bad idea? Perhaps in combination with "custom element" for uniqueness as Macrura said...

Share this post


Link to post
Share on other sites
19 minutes ago, d'Hinnisdaël said:

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?

That's correct. It's a bit of a nuisance, admittedly, but I don't consider it a huge issue. It's a whole different deal when we're talking about other bundled classes – in the case of Wireframe, for an example, I already have View, Component, Controller, and Config, which would be very likely to cause issues if they weren't namespaced. In fact most of my own recent modules come with a Config class... 😛

19 minutes ago, d'Hinnisdaël said:

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 🏓

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. But obviously it's your call – if you want to do your best to avoid any issues right now, renaming would be a safe bet. It'll force existing users to likely reinstall, but that's unlikely to become a massive issue.

50-50 🙂

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

I just tried to implement custom namespaces for all of my SnipWire "extra" classes (service, helpers, installer, ...) but it seems to be a huge modification = a lot of work!

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.

Do you think its a good idea to use custom namespaces which lie within the ProcessWire namespace:

ProcessWire\SnipWire\Helpers
ProcessWire\SnipWire\Services
...

Besides, I have little experience with namespaces in PHP ...

Share this post


Link to post
Share on other sites
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:

 

  • Like 2

Share this post


Link to post
Share on other sites

Solved! I just release an update which moves all custom classes into custom namespaces.

Thanks for your help!

  • Like 1

Share this post


Link to post
Share on other sites

this module is amazing...lots of possibilities, thanks.
One quick...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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
6 hours ago, d'Hinnisdaël said:

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.

ehm..it shows empty lists now

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
9 minutes ago, d'Hinnisdaël said:

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.

sorry, this issue is not related to the multiple instances, it was broken even before, with one page lister and i forgot to write a post about it and got in my mind now

Share this post


Link to post
Share on other sites

@d'Hinnisdaël first of all, thanks for making your dashboard public. 

I am currently building a small Intranet Application for my department and want to include some charts. 

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 😞

This is my code, maybe I am overlooking something...

$group->add([
        'panel' => 'chart',
        'size' => 'normal',
        'title' => 'Kostenvergleich',
        'style' => ['centerTitle' => true],
        'data' => [
          'chart' => [
            'type' => 'pie',
            'data' => [
              'datasets' => [
                ['data' => [floor($normalTotal),floor($recurringTotal)]],
                ['backgroundColor' => ['rgba(193, 66, 66, 1)','rgba(193, 66, 66, 1)']],
               ],
               'labels' => ['Einmalig','Laufend']
            ],
            'options' => [
              'responsive' => true
            ]
          ]
        ]
      ]);

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
2 hours ago, d'Hinnisdaël said:

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.

Sadly makes no difference

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      TrelloWire
      This is a module that allows you to automatically create Trello cards for ProcessWire pages and update them when the pages are updated. This allows you to setup connected workflows. Card properties and change handling behaviour can be customized through the extensive module configuration. Every action the module performs is hookable, so you can modify when and how cards are created as much as you need to. The module also contains an API-component that makes it easy to make requests to the Trello API and build your own connected ProcessWire-Trello workflows.
      Features
      All the things the module can do for you without any custom code: Create a new card on Trello whenever a page is added or published (you can select applicable templates). Configure the target board, target list, name and description for new cards. Add default labels and checklists to the card. Update the card whenever the page is updated (optional). When the status of the card changes (published / unpublished, hidden / unhidden, trashed / restored or deleted), move the card to a different list or archive or delete it (configurable). You can extend this through hooks in many ways: Modifiy when and how cards are created. Modify the card properties (Target board & list, title, description, et c.) before they are sent to Trello. Create your own workflows by utilizing an API helper class with many convenient utility methods to access the Trello API directly. Feedback & Future Plans
      Let me know what you think! In particular:
      If you find any bugs report them here or on Github, I'll try to fix them. This module was born out of a use-case for a client project where we manage new form submissions through Trello. I'm not sure how many use-cases there are for this module. If you do use it, tell me about it! The Trello API is pretty extensive, I'll try to add some more helper methods to the TrelloWireApi class (let me know if you need anything in particular). I'll think about how the module can support different workflows that include Twig – talk to me if you have a use-case! Next steps could be a dashboard to manage pages that are connected to a Trello card, or a new section in the settings tab to manage the Trello connection. But it depends on whether there is any interest in this 🙂 Links
      Repository on Github Complete module documentation (getting started, configuration & API documentation) [Module directory pending approval] Module configuration

    • By MoritzLost
      Process Cache Control
      This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Plans for improvements
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots


    • By Macrura
      PrevNextTabs Module
      Github: https://github.com/outflux3/PrevNextTabs
      Processwire helper modules for adding page navigation within the editor.
      Overview
      This is a very simple module that adds Previous and Next links inline with the tabs on the page editor. Hovering over the tab shows the title of the previous or next page (using the admin's built in jqueryUI tooltips.)
      Usage
      This module is typically used during development where you or your editors need to traverse through pages for the purpose of proofing, flagging and/or commenting. Rather than returning to the page tree or lister, they can navigate with these links.
      Warnings
      If you are using PW version 2.6.1 or later, the system will prevent you from leaving the page if you have unsaved edits.
      For earlier versions, to avoid accidentally losing changes made to a page that might occur if a user accidentally clicks on one of these, make sure to have the Form Save Reminder module installed.
      http://modules.processwire.com/modules/prev-next-tabs/
    • By Gadgetto
      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-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 ----
       
×
×
  • Create New...