This module uses the amazing Flickr API module to provide Bean integration. With this module, users can easily create blocks that fetch Flickr images. Currently it provides two ways to search (per block):
Search on a given string
This can be used to show a blocks photos mentioning the client name, for instance.
Search on terms used in the given entity
This can be used to fetch related photos. Suppose you have vocabulary Section (eg: Football).
In the end, one argument against using Views for our content queries overrode all others: we wanted our client to use Views. Our client had specified that once they received the sites, their own developers would be using Views to build blocks and pages themselves. We knew that if we worked in Views for our own work, the Views we created would eventually be exposed to them, which leads to possibilities of regression and error. We wanted our core querying functionality to continue to function without concern that it might be tampered with.
wondering why I wouldn't just build this in Views. Indeed, this might look a bit masochistic if you're used to Views. However, there are a few things to consider:
EntityFieldQuery is core. If you are interested in keeping your installation as lean as possible, this is something to consider. Views is a contributed module, and so it automatically adds size and overhead to your Drupal install.
EntityFieldQuery is small. The amount of code required to generate an equivalent listing in Views, compared to what we built above, is much, much greater.
By my rough count, there are 150 contrib projects for Drupal 7 that declare new field types as part of their central module. I've listed the projects here by their usage statistics.
Taxonomy View mode allows for each Term page to use a Taxonomy view mode instead of the default hard code view.
This allows the term page display to be a list of the fields on the term (much like is done to nodes).
The TVI (Taxonomy Views Integrator) module allows selective overriding of taxonomy terms and/or vocabulary with the view of your choice. Using TVI you can easily create custom views to output all terms in X vocabuarly.
my content (nodes) are original to my site, but the terms that describe it (taxonomy terms) are concepts that are part of universal, cultural and scientific truths that exist independently of the content on my site. For these concepts, I only need a name to represent those concepts. Taxonomy.module is a place where relationships of meaning are played out against the content of my site.
Taxonomy.module is basically three unique things:
1. An inflexible hierarchical relationship.
2. Free-tagging or the automatic creation of entities by name.
3.
Identity Services: Authentication, authorization, and access to the service catalog.
Object Storage (Swift): Access to containers, objects, and all related services.
CDN (SOS): Edge-side caching of objects from Object Storage.
Drupal offers a variety of solutions to address multiple sites with shared and separate content. As with all things Drupal there is no right solution - just options for your specific needs. Evaluate your goals and make decisions based on them; you may find that Domain Access is a better fit for your content editors or a multi-site setup is much easier to manage for your system administrators.
The votes have been tallied for the first annual Blue Drop Awards
and the team of volunteers is proud to announce 2012 winners across nine categories. With over 200
website nominations, the community has voted and selected innovative, progressive and dynamic sites.
The winner of the 2012 Drupal Website of the Year is Eyemaginations.com, developed by Unleashed
Technologies, LLC of Columbia, MD.