If you have spent any time in our Slack or Gitter then you know there is one thing that drives me crazy, the number of modules it takes to run a thirty bees shop. There are so many modules that are not needed as separate modules. This clutters the page in my opinion and helps to scare off new users. At the same time it makes things harder to find. Do you edit this address in the Block Contact module? The Block Contact Infos? Or is it on the Preferences Store Contacts page?
To me, this is just insane. This crowds the module page and creates a huge mess for users. Did you know in a thirty bees installation there are 26 statistics modules installed by default? That is 26 modules you have to scroll past to find what you are looking for. Of those 26 modules only 3 of them need to be separate modules. We inherited a maddening array of module mess. Not only does this mess make your back office look cluttered, it is hard for us to upkeep 26 different repositories. They have to be put in the feed, they have to be maintained with bug fixes and builds. Not only do we have the problems I just mentioned, but they also slow down the installer as well. They can create timeouts drawing the sources from our API.
The better way
One of the community members that helps out a lot with thirty bees, Fabio from Nemops helped us create a better way. He condensed 23 of the statistics modules down into one main statistics module. Starting in version 1.0.4 thirty bees will be shipping with one combined module to handle all of the statistics. This means a cleaner module list for you the merchant. The statistics will still function as the have in the past, the only change will be that there is one module holding all of the classes that make up the statistics. This change allows us to easily add new types of statistics over time easily, without introducing new modules to maintain. So in our GitHub repository you are likely to notice that there will be new modules added to the deprecated list. Don’t worry, it is just because we are trying to combine down as many as possible, so we have less code base to deal with and can deliver more modules, and keep the back office easy to navigate. We are experts in trying to keep things simple.
Have a comment on this approach? Let us know below!
