search

drupalwxt / wxt_bootstrap

Bootstrap derived sub-theme aligned for use with the Web Experience Toolkit jQuery Framework.
8 stars 3 forks source link

List core hacks & dependencies in project page #13

Closed mgifford closed 4 years ago

mgifford commented 4 years ago

It is useful to make sure that any hacks to core and module dependencies in the theme are clearly laid out in the project page so that folks are able to catch issues early and not be surprised in the middle of trying to implement the theme.

Also, it is mentioned that the distribution is recommended, but not why. If you've already migrated a site to Drupal Core, why not just add in the theme if that is all that is missing?

zachomedia commented 4 years ago

@mgifford Can you clarify what you mean by "hacks to core"? Like are you referring to patches to Drupal Core? As far as I know, the README https://github.com/drupalwxt/wxt_bootstrap#standalone mentions the required dependencies to run the wxt_bootstrap / wxt_library.

@sylus believes there are no patches in wxt that facilitate bootstrap, but we will double check.

We can add the following blurb as to why to use the distribution:

  • Configuration of the WxT components and custom plugins (that only profile can run)
  • Drupal lifecycle and updates of core and additional Lightning extensions
  • Workflow improvements and configuration of contributed modules
sylus commented 4 years ago

Hey @zachomedia based on discussion I made the following adjustments which should answer everything.

https://github.com/drupalwxt/wxt_bootstrap/commit/095a501bdf70187b5110b875ed48d0205b8ac6ef

Thanks for taking the time!

mgifford commented 4 years ago

Ok, if patches are required to Core, then say that in the project page up-front. I don't know what the patches are or why they are there. I'd love to see a list of what patches are required with links back to the issue/comment on drupal.org where they are being discussed. Hopefully they get included in upcoming releases of Drupal 8 or 9 going ahead.

The point is to make it clear up-front that you need to do something that is generally a no-no. So much so that there are stickers & songs written to highlight why it is a bad idea - https://www.youtube.com/watch?v=CjL8E-C8-Xc

I'm not arguing that patches shouldn't be included, but they should be very carefully explained, and when they do get included in a Core release should be struck through so that folks know that these patches no longer need to be applied.

Again, if you are officially not supporting this theme and only supporting the distribution, then say so. Just leave these issues open and ask for people in the community who use this theme to step up to maintain it.

Preemptively closing issues isn't a good practice in community building.

zachomedia commented 4 years ago

@mgifford We understand that some documentation may be lacking, and while we are constantly adding and improving documentation, we have focused on areas raised by the community to ensure that they can succeed in their projects. For every issue that you have opened so far, we have addressed and documented as requested.

Should you feel that the documentation that has been provided is incomplete or can be improved, we happily accept contributions from the community. This issue was closed because the original issue was address. This would fall in line with standard development practices in any project. Should you have continued concerns about documentation that has not yet been addressed, we are happy to have new issues created for those on Drupal.org.

Regarding wxt_bootstrap / wxt_library and their support both with and independent from the wxt distribution: the distribution uses the 2 modules directly. Ensuring that the modules are up to date and functional is a core component in the WxT release process (https://github.com/drupalwxt/wxt/wiki/Release-process). We offer them separately for those who aren't able/interested in using the distribution. We offer limited support for those setups (ie. we will try to help when we can) because we do need to prioritize the time for work that will have the largest impact on users.

Of the users we've been in contact with, they are using the distribution instead of rolling their own Drupal install using wxt_bootstrap. This is why our support focus is currently on the distribution. To ensure this is well documented, we even added a notice about this on the wxt_bootstrap project page (@sylus's comment above).

Just a quick note about some of the additional benefits of the distribution:

The distribution is also fairly lightweight, contains many optional features. Lightning provides a a base, some pre-configuration, authoring lifecycle (enterprise authoring) as well as many upgrade paths. We also have a relationship with Acquia, who provide us support when needed and builds components that goes into core. They've also provided us the base for the composer workflow and upgrade paths. Lightning is use in many large organizations and has a 2000 site install, and Acquia recommends using it as a base especially for governments.

We understand that not everyone may be interested or able to use those features, however, and again is why these modules are separate from the distribution.

sylus commented 4 years ago

Thanks @zachomedia and sorry I closed the issue it was because I thought we addressed the specific issue as the title of the issue was worded to something specific and I pointed to the commit. Additionally I thought we had a discussion earlier where you asked us where we prefer issues and we both agreed to Drupal.org. Sorry about that.

We are definitely trying our best to accomodate as best we can. Really sorry if we fall short in some areas. :( Both me and Zach do this all essentially in our open source time now since we are in a different field now at StatsCan. The WCMS team at stats only takes the reins once Drupal 7 is sunsetted in the next 4-6 months and then should have a team of between 5-8 supporting it.

In general from the departments I have heard form they were pretty happy with our work and we already have 3 depts in production one for over 2 years so we also have to maintain upgrade paths and support for them. I know of 3-5 others that have it in the pipeline so also want to make sure their path is as smooth as possible.

Lightning itself has been great as the people who maintain it have worked closely with us in the past and many huge sites run with it as a base. It itself whole goal is to be a base framework from which to build upon. They even solve all of the complicated upgrade paths for us such as when panelizer was deprecated by layout builder, and even the composer workflow in general which is now the recommended practice for building drupal sites though we early on to that. Additionally they have slowly moved all their logic into their component modules so at some point we will also lose the profile dependency which is planned in the long term.

As for the notes themselves we do always update the README.md for all of our main projects but sometimes we do forget to upgrade the documentaiton pages on Drupal themselves as they are a bit more work and not in markdown. I have added that to the release process so they aren't missed and we try to sync up with the README.md files.