Snowman: Phase 1

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
eaton's picture

What comes next for the Snowman project? At the Drupalcon BoF, we nailed down some clear goals for the project and resolved a number of outstanding questions about purpose and target audience. We could start having arguments and bikeshed discussions about specific features, layout, and so on. But because that's not awesome, we're not.

Instead, at Leisa Reichelt's suggestion, we're going to approach it the way designers handle the brainstorming phase of a project: we're going to build some simple sites that mirror what we'd want Snowman to be used for. We'll study those real built-out sites, discuss what common threads emerge, and nail down our gameplan for the profile. At this point, anyone interested in helping with the Snowman project should do the following:

  1. Read up on what's been figured out already (see the FAQ, the Personas discussion, and the BoF writeup).
  2. Write out an actual 'story' for a group that matches the Snowman use case. (See The Snowman R&D Page for examples: they don't have to be long, but they should give enough precision and personality to give the general use case some life.)
  3. Fire up a copy of Drupal 7 and start building a web site that serves that group's needs! Remember that we're only using the tools available in Drupal core. No contrib modules or themes allowed!
  4. Post a note about the site you're working on to the Snowman R&D Wiki. If you run into particularly interesting questions or insights, start another discussion here so the rest of the Snowman Crew can talk through it with you.
  5. As you build out the site, keep track of the 'gaps' in core functionality that you find, large or small. Whether it's managing a mailing list or changing how many nodes appear on the front page, make a note of it and keep track of how it would improve the site for users.

In a month -- about the middle of April -- we'll close up this experimental R&D phase and look over all of the sites together. We'll be looking for common patterns that emerge with sites for these kinds of groups, unique and cool tricks that some of us come up with, and insights into what walls we hit with core's built-in capabilities.

From there, we'll start putting our plan for Snowman's specific feature set together. The 'gaps' we spot in core functionality that keep us from implementing server features can be handled in one of two ways: we can brainstorm simple patches for core that would make them possible, or we can use them as 'on-ramps' that nudge new site owners towards Drupal.org, the modules directory, and the world of site building.

Let's build a snowman!

Comments

1 Gap is lack of Views in

dalin's picture

1 gap is lack of Views in core. This forces us to use Taxonomy as a hammer and everything is a nail as Taxonomy module is the only thing in core that can create lists of stuff.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

You could build listings via

catch's picture

You could build listings via EntityFieldQuery or SQL, and stick that in snowman.profile. If it really is profile specific then this would be fine. It doesn't allow people to tweak those listings either, but that's the same with blog/forum/taxonomy modules so no worse than what we have already.

...

Jeff Burnz's picture

Very simple missing feature are listing pages for node/[type]/xxx, this opens up a lot of scope for building lists of content and avoids being forced to use Taxonomy as the hammer or the hell that is Views UI (for beginners), such as http://drupal.org/project/get_content_type

The New Views UI in

grimfandango's picture

The New Views UI in 7.x-3.x-dev, IMO, lowers the bar significantly when using Views. Whether it lowers it enough is another question.

Book is another alternative

eaton's picture

I know of quite a few sites using Book module as a lightweight alternative for managing hierarchy and sets -- it's possible that a simple patch could turn it into a viable alternative for small amounts of content that need to be displayed dynamically.

There are two very early patches that I've proposed for D8 that might be able to remedy the situation... http://drupal.org/node/1066830 and http://drupal.org/node/1050664 in particular might be of interest.

What's popular opinion on

Bastlynn's picture

What's popular opinion on using (abusing?) PHP filter to get the display of information needed?

This seems like it would

deviantintegral's picture

This seems like it would deviate from the purpose of the profile, which would be to show what Drupal can do without any custom code. Plus, the PHP filter is just plain evil, and using it in the profile indicates that it's a best practice when it's not.

IMO it should never be used.

dalin's picture

IMO it should never be used. See the Bad Judgement module:
http://drupal.org/project/bad_judgement

The PHP filter makes your site easier to break, easier to hack, harder to maintain, and decreases performance (PHP in the database can't be cached by APC).

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

If the idea is to use what

Bastlynn's picture

If the idea is to use what Drupal gives you out of the box directly without touching a line of PHP - then the same argument applies to building custom listings in the profile - see catch's suggestion above. At least PHP filter is something the site owner could reasonably (if unwisely) do themselves from the UI.

While building custom views in the profile makes more sense than using PHP filter from a best practice point of view, I think we really need to get to a group consensus on custom coding in the profile to clearly define which techniques are in play and which ones aren't.

Are we allowing any form of custom code in these profiles?

A site owner can copy and

catch's picture

A site owner can copy and paste blobs of PHP into foo.profile as well as they can the PHP filter, it's still PHP code. I'd like to see us remove the PHP module from Drupal 8, and consider shipping with a mysite_default.module that can be copied to the modules directory similar to settings.php to hold custom code instead.

The actual Snowman profile that will ship with core is going to include some code - even if it's just in the .install/.info file to add node types, taxonomy vocabularies/terms, enabling modules, setting a few permissions etc. A small amount of glue code in the .profile is fine alongside this.

If you put hundreds or thousands of lines of code in the .profile then that's cheating on Eaton's task, and it'd be worth seeing what's doable without any code at all, but I think it's better to have a bit of glue code than balk at not having Views in core.

Please understand I'm totally

Bastlynn's picture

Please understand I'm totally doing the devil's advocate thing here. I want to make sure we've got a well reasoned and clear set of constraints as we go forward. So - counter arguments are good. ;)

Profiles are certainly going to have a lot of code in them (as you mentioned, to shortcut configuration and to load starting data) but from how I see the task in front of us if any of that code isn't something the user can do from the UI then that entirely subverts the point of the project. In effect that would prove that Drupal is not usable from base code. Which boils down to: I think even glue code (such as to replicate a Views style listing, even if it's just a handful of lines) - constitutes cheating.

As a measuring stick - I would say if the profile code, post-install, still needs to be active in the system or certain pages would break, then it's failed the goal.

What about something like "Simple views"

travisc's picture

Maybe its out of the scope of this project, but the interface is certainly accessible to novice users.

What about sticking to the

yoroy's picture

What about sticking to the challenge of using core only and see what you can do with it :) "Needs Views" is too easy a cop-out imo.

For example, I figured out I can build a simple comment notification system by using the core actions/triggers tools: "send an email when a new comment has been posted" can be done using core only. Just an example.

Keep in mind that Drupal 8 core will not be the same as D7 is now, and I'd be fine with assuming 100 lines of custom code or so, but try and get creative with the core tools. Constraints are good.

Completely agreed. By the way

catch's picture

Completely agreed. By the way I'm sure it'd be possible to do per-content type listings of nodes in less than 100 lines ;)

...

Jeff Burnz's picture

I think what we're saying here Roy is that some way of making lists other than using taxonomy is a gap, for example in my R&D site I really want a list of news type nodes, but I can't have this without using taxonomy. I am using taxonomy due to using Forum module, however its really odd to my content creators that even though they are creating a "News node" and have to tag it with "News" to get it show up in the "News" page. It was also an additional step for the site builder to have to learn all about adding a taxonomy field and how to get this into the content type - which took him a rather long time and much head-scratching.

Yup, understood

yoroy's picture

I definately recognize the 'why do I have to tag it as news when it is already created as a news content type?" weirdness. Definately a gap.

Just want to encourage you all to continue experimenting instead of diving into 'how to fix' discussions' too soon!

Errr. How does 290 lines

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

whoops. The real

dalin's picture

whoops. The real URL:
http://snownpo.communit.ca/

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

How about an installation profile for....

jdonson's picture

How about a Drupal 7 installation profile for a Drupal instance that auto-supports:

  1. WordPress-Like Admin UI (THEME)

  2. WordPress-Like Blog (THEME)

  3. WordPress-Like Starter Set of Capabilities (MODULES???) ... ("Drupal Light!")

  • OR -

How can we migrate from WordPress to Drupal?

THANKS!

Jeremy Donson
Database and Systems Engineer
New York City

Snowman

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: