Skip to content

Home

Jump to bottom Edit New page
Miro Marchi edited this page Nov 28, 2013 · 21 revisions

Welcome to the developing wiki! These wiki pages are part of the main wiki documentation of retebuonvivere project.

Since building profiles has much to do with all the developing workflow (soft/hard configuration, makefile, distributions, ...), this wiki will be the main wiki for all developing stuff.

table of contents

developing workflow

We are going to follow a code-driven development workflow for our custom modules and configuration, in order to boost teamworking. Reference for this can be found at nuvole.org/blog/code-driven-development, see further for more documentation.

Expecially we are going to:

  • use features;
  • follow the distinction between soft-configuration and hard-configuration;
    • hence using features to store hard-configuration;
    • and installation profile to store soft-configuration.
  • make stuff updatable with hook_update_N() and hook_install() (we don't do this yet, nor we have a controller feature, only because I (miro) am not capable of implementing these workflow techniques without the help of a programmer).

documentation

profiles

code driven development

distribution

Retebuonvivere.org could become a new drupal distribution (allowing other networks to use it besides Verona's).

If we go for this choice, above there are sone links to specific documentation for working with distros to start with.

Another choise is to work on top of one of the social distributions out there, e.g. Open Atrium 2 and Drupal Commons 3, or on top of a base distribution as Panopoly.

social distros

Both Open Atrium 2 and Drupal Commons 3 are great, rich, powerful barebone social networks. This implies that they highten system requirements (php memory limit, apache solr, ...). I(miro)'m not an expert but I think this can be a problem because we want to stay light, making it easy and cheaper to find a hosting solution). It could probably be possible to remove some funcionalities and lower requirements (but this implies a certain amount of re-configuration). A good reasong for doing this is that a lot of configuration we need is already done with these distros.

There is also another important point: both of them are aimed at levereging an online community. They are full of superb funcionalities for messaging other users, following contents, managing user dashboards, sharing content... Perfect for an intranet, for instance.

retebuonvivere distro diff

Retebuonvivere.org is slightly different:

  • it aims at being a (self)representation and cooperation tool for a community which is fragmented and whose members and groups already use a pletory of different tools:
    • web-based (emails, mailing-lists, online groups, instant messaging, social networks, ...);
    • non web-based tools (telephones, faxes, notice boards, notebooks,...);
    • in-presence modes (direct face-to-face talking, conferences, meetings, sociable events, ...);
  • each member and group uses a cobination of these tools and modes in a unique way.
  • member's organizations (most of them) also maintain a propretary (main) website.
  • They «don't need a "new social network"».

For these reasons we:

  • do not implement messaging funcionalities;
  • focus on tools with a network scope (see feature documentation) such as:
    • the graph, which allows to see all the network of relations between organizations. This should produce fill the gap of consciousness of being part of a whole; should produce an understanding of the complexity at place.
    • shared calendar.
    • discussion forum and the wiki.
  • and then working on connecting other websites, with functionalities like:
    • importing content (from RSS feeds, from social networks like facebook, wiser.org, zoes.it, from calendars,...);
    • feeding other websites with content created in retebuonvivere.org (connecting with facebook API...).

base distro

Panoply is a base distribution. Open Atrium for instance is built on top on Panopoly.

Panopoly requirements are easier to reach (Apache solr is optional, memory limit is 196MB not 256MB, ...).

What it does is to tie together a lot of funcionalities about:

  • layouts (based on panels);
  • editing (wysiwyg, linkit, ...);
  • media (media, video panel, ...); So, no organic groups configuration (to be clear!).

This means that a great number of patches (and dev versions) are applied by the maintainers of panopoly.

Documentation

Test

  • We could take this as a starting point and add our funcions.
  • We performed a simple test: installing our features (rbv_com fields, rbv_org, rbv_rel, rbv_relpro, rbv_groupcontent) in a clean Panopoly distribution. It needed only one patch (working on the coexistence of og and FAPE modules) and it worked out perfectly! Check out issue 8.
    • A small issue we had before was that panels layouts were not responsive by default. With panopoly it is by default.

What's next?

This entire conversation about whether to use a distro (and which one) is still open. What do you think? (open an issue, write an email).

Further question: should we go panels panels panels + media → panopoly or should we go blocks and contrib modules configured by ourselves → continue without a base distro?

→ chek out display-related section of (rbv_org) wiki if you are interested in displaying stuff.

I quoted the questions above because we have decided to go panels and panopoly.

→ For documentation see Developing Distributions with Panopoly.

Update: we built our profile and makefile in order to have our distribution on top of panopoly and drupal core. Check them out.

Add a custom footer
Add a custom sidebar
Clone this wiki locally