Commons is spread across many projects. The initial intention there was to make it easier to re-use components of the distribution inside other distributions, and to assemble sites with specific sections of the distribution. Where possible, Commons is architected to avoid dependencies (eg, Commons Radioactivity alters views defined by other modules to add a Radioactivity sort when it is enabled, thus preventing folks from having to use Commons Radioactivity if they don't want it for their site, Commons Profile Base is used in COD and has roughly 1.5-2 times the number of reported installs as the Commons distribution.).

One drawback to this approach is that it can increase the complexity of contributing to the distribution. For example, amitaibu pointed out that #1969088: Changes to group browsing widget & user status updates requires several patches to implement or review a single issue.

So, which components shall we move into the main repository?

I propose we start with all of the content type modules and the landing page modules, though am certainly open to establishing criteria or a general rule of thumb to figure out which components belong where.

#14 rebuild-registry-1983606-14.patch478 bytesDevin Carlson


Zarabadoo’s picture

Moving the content type would be a good start. Hopefully it would simplify general changes to those types. One thing that I can think of off of the top of my head is the rewriting of the submitted information on the nodes. Currently it is done in the theme as that only required a singular patch instead of 5. I am someone that subscribes to only performing string changes in modules, so if it makes this easier along with other string changes, I am all game.

As for a rule of thumb, it depends on how specific something is. At this point, the theme could almost be loaded in there as it really has no purpose outside of Commons. I cannot see how it can be used with any other type of site.

ezra-g’s picture

Thanks for the input, Zarabadoo.

One other benefit to spreading the components across projects is that it provides more granular usage statistics. It would be particularly interesting to me to know the approximate percentage of sites that run Commons stick with the out-of-the-box IA. So, I agree that the Origins theme isn't particularly useful outside the distribution, but I wonder if it's worth keeping as its own project in order to retain the usage data.

rickvug’s picture

For what it is worth this was my first impression as well. I wanted to see all of the Commons code together in one repository with one change log. While I completely agree with re-use, I don't necessarily think that having Commons modules in their own projects is the way to go about this. On the contrary, I would say that once a Commons module becomes generally re-usable, it should then become its own "pure" contrib module without the Commons name attached (Commons in the name makes me presume a hard dependency).

jrbeeman’s picture

I understand the desire to simplify the structure for contributors. It's too bad there isn't more of a happy medium, but I also have no idea what that middle-ground would look like. I think it makes most sense to start with structural modules (content type, vocabulary, etc. definitions), leaving functional features in their own contrib areas.

Thinking out loud... SVN as a repository structure would have gracefully handled this by allowing you to maintain all of Commons in a single repo, while also allowing others to just checkout one or a few folders (modules) from within it if they desired. I'm not aware of similar functionality in Git, but perhaps it exists?

brantwynn’s picture

I think that it is okay for a module to remain as its own project unless it will never be able to be used outside the Commons distribution. Thinking about something like commons_body and the content types that depend on it - that is something I would include with the distribution.

If the goal is to decouple these Features as much as possible so that one can possibly use portions of Commons without all of Commons, then those modules must remain as their own projects. This is the paradigm that Panopoly follows where a lot of effort is being made toward decoupling its best modules- making it so that any of them could be used without the panopoly_core/full distribution. Because of this, we have been able to use some, but not all of Panopoly in a "macro-distro™" (Demo Framework) without having to carry along extra, unused dependencies.

@rickvug: I don't agree that once completely decoupled, a module needs to be renamed - its perfectly okay, to me, that a component originally intended as part of a distribution might keep the distro-assignment but also be used elsewhere. Not only to carry forward the namesake of its brethren, but also because changing project short names is generally messy business. Just ask the developers behind Metatag(s)...

japerry’s picture

I used to be very much in the camp of lesser is more simple, thus better -- but I've since changed my standing to be closer in line with the panopoly way of doing things. Sure, it takes a bit more work on the maintenance side, but we've gotten build scripts and processes to do most of the heavy lifting.

Content types are one thing I might include with the distribution, mainly because of the hard links fields have to other fields, and the difficulty people run into when trying to change that.

Referring to the original issue, making patches for multiple projects -- I've gotten into a pretty nice pattern. I have the repos all symlinked in my editor, phpstorm, and they also live in tower. Its very simple to see which projects I've hit when i need to roll a patch, or multiple ones, and the process is fairly straightforward.

Before refactoring this whole process, I would like to evaluate the tools contributors use. Perhaps they aren't the best for this type of scenario.

amitaibu’s picture

@japerry ,

I have no problem with decoupled/ generic modules - they are great, no argument here. My stand, however, is that modules such as commons_groups and commons_bw are not distribution agnotstic. I can't think of one use case where I'd want one of them in another distribution.

I think it should be done the other way, like in kickstart. Modules start custom, and when they mature and cleaned-up they can be moved to contrib (e.g. Commerce Backoffice)

greggles’s picture

Having read nothing but the title.... ;)

One of the things I find very important to the success of distributions is that the pieces that are generally useful should be split out. A great example is cod_support (300 installs) and uc_signup (600 installs). By splitting out uc_signup it became much more likely that someone would say "Oh, I need that and will install it." That benefits the distribution because now there are more users (tester/contributors) to the sub-module which benefits the broader distribution. I think that could be used as a test to decide what should be broken out from the distribution: will people find this generally useful so much that they decide to install it without the distro?

One other thought is that when things are in the same project it seems to make it easier to make them interdependent. I find that makes distros less useful so I hope folks will be cautious about that. For example: what if I like and want commons but don't like the way commons does Wikis. I want to be able to turn off the commons wiki feature and have everything else work. If all content types go into one place, just be sure that place still keeps the individual content types separate.

ezra-g’s picture

Priority: Normal » Major

Bumping to major because of the pain this caused at #1969088: Changes to group browsing widget & user status updates.

I propose we move into the Commons repo, as a start:

- commons_documents
- commons_events
- commons_featured
- commons_pages
- commons_polls
- commons_posts
- commons_q_a
- commons_site_homepage
- commons_user_profile_pages

rickvug’s picture

Version: » 7.x-3.x-dev

The list in #9 looks like a good start to me. Why not Commons Body Field, Commons Event, Commons Profile and some of the others? What rule of thumb is being used for the specific modules listed in #9?

japerry’s picture

Assigned: Unassigned » japerry

I've started this process by using a new branch in commons called 7.x-3.x-merged. We can test the install there until we're ready to move everything over.

japerry’s picture

Issue tags: +Commons 7.x-3.4 radar

Tagging to 3.4

ezra-g’s picture

On first glance this looks great to me. Needs some upgrade path testing but mostly seems great.

Devin Carlson’s picture

I didn't have any issues installing Commons using the 7.x-3.x-merged branch and the only problem I had when upgrading from 3.3 is the, expected, registry errors.

Attached is a patch with an update function to rebuild the registry in order to accommodate any classes that were moved.

japerry’s picture

I've updated the build_distro script to facilitate easier building. Will work on integrating it into the file that kickstart uses so we're closer in consistency with them.

Note: It'd be neat to have a distros module drush script that did this stuff for us.

Command: commons_profile/scripts/ build [Full-path-to-directory] [d.o-username]

japerry’s picture

hmm I've been playing around with it, and I get this issue when running updb...

drush updb
The following updates are pending:

commons module :
3107 - Rebuild the registry to accommodate Commons modules merging into the profile.

commons_groups module :
3112 - Update the og group filter inside views per http:drupal.orgnode2037417.

Do you wish to run all pending updates? (y/n): y
failed to open stream: No such file or directory
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: require_once(): Failed opening required
(include_path='.:/Applications/MAMP/bin/php/php5.3.14/lib/php') in /Users/japerry/Sites/commons2/publish/includes/, line 3119
The external command could not be executed due to an application error. [error]
Finished performing updates.

japerry’s picture

Status: Active » Fixed


All of the repos are merged into the head branch. We'll need to go back and start removing projects now.

make sure you run updb and or after applying the new codebase!

In most cases, a drush updb should work, but if you have anything special on your site, its possible that you'll need to execute registry rebuild directly. If there are questions, please post them here.

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Fix href syntax