The project was a cooperation between brandmarke hamburg and comm-press. We started in an unusual way. First we gave the concept and the tasks to comm-press so they build up the core system and manage the main output. Our main part was the theming and frontendcoding. We got a new colleague Frantisek and this was his very first job in this company. We didn't know each other before so there was a little risk to let the new colleague Frantisek work alone on this project. That is we decided to work together with comm-press and keep the project save. It was not easy for Frantisek coming into a new country and come in use to a different language cope with the situation to work with a company and get into their workflow. But he did a real good job. Thanks Frantisek! On this point I want to thank comm-press too for being this nice to spend a lot of time for Frantisek in addition and bringing the community thought into our company.
Project summary
Frantisek wrote a summary on this project with technical details:
The building of the whole project could be split into small pieces regarding the page content. There was mostly textual contents with banner image but also more difficult content types like music, video, store search and lexicon search. The front module should be able to handle various block content which could be moved and stretched dynamically via jQuery. This module is provided on drupal.org under the name Front blocks.
The backbone of the portal was set by the comm-press team. The content types had their specific contents, everything was pushed to the front via webform, views, panel pages with various node templates also as exposed filters which could be changed by the users.
Within my personal tasks I had to make the front end, animations and the views handling regarding an already presented and accepted by the customer XHTML template. That meaned a lot of views template work, jQuery animation and a bit non standard css absolute positioning what was strictly necessary in some special cases. I wouldn't encourage to use such practices only as last solution. The portal should be IE7,8,9 and also iPad compatible.
What the css markup goes, here I would encourage all backend developers to put their content in separate content types instead of grouping content into “teaser, title, body, teaser image” fields for each page + some special fields due the feature of specific body class markup based on the content type.
Let me give you an example of that. If you are making a “general” content type which groups the main fields and filter the distinct fields via JS at backend, you end with all pages having the same body markup and cannot specify css specific tags right underneath the body element. Like instead of having .general_type body class, you need to have .first_type, .second_type for your page content markup. Also the theming feature of making template specific tpl files linke node—specific_type.tpl.php (see: http://drupal.org/node/1089656) will be lost.
In case that you would decide to use one general content type and to show/hide the form content regarding this, here's a good solution jQuery to handle the fields:
<?php
(function ($) {
Drupal.behaviors.christ_tools = {
attach: function (context, settings) {
// check with firebug the -> tid ?
var formFields = new Array();
// headerimage
formFields[0] = new Array('#edit-field-header-image', 1, 3); // when this option selected, fields 1 and 3 will be shown
// each field that you want to show/hide has to have one of this
// find preselected option
var preselected = parseInt($('#edit-field-category-und').find('option:selected').val()); // edit-field-category-und = select box element id
$.each(formFields, function(intIndex, value) {
if (jQuery.inArray(preselected, value) > -1) {
$(value[0]).show();
}
else {
$(value[0]).hide();
}
}
);
// manipulate form on change
$('#edit-field-category-und', context).change(function() { // select box element id
//var fieldValue = jQuery.inArray(parseInt($(this).find('option:selected').val()), formFields.text);
var formFieldSelectedVal = parseInt($(this).find('option:selected').val());
// run through array, check if selected value is in the array
// if so show element, else hide it
$.each(
formFields,
function(intIndex, value) {
if (jQuery.inArray(formFieldSelectedVal, value) > -1) {
$(value[0]).show();
}
else {
$(value[0]).hide();
}
}
);
});
}
};
}(jQuery));
?>About multimedia content pages, they was set via node template panel pages where additionally, the view of all files was shown at each page. There was used the flowplayer music and video player solution where I've added the library like:
flowplayer files→ within the directory sites/all/libraries/flowplayer
Then access the libraries within your module/callbacks like:
<?php
if ($path = libraries_get_path('flowplayer')) { // load flowplayer
drupal_add_js($path . '/script.js');
drupal_add_css($path . '/style.css');
}
?>Then the markup via views and templates had to be adjusted and the rest is handled by the jQuery scripts.
Another specialty that was developed for the customer is the wallpaper image downloading feature. This feature provides the file with the preset name for download instead of opening a new page with the image. The wallpaper page is an content type with image fields where the pictures are uploaded in various proportions (3:2, 4:3, 16:9, 16:10) in their biggest size. These pictures are later scaled to smaller resolutions. The downloading of these files is handled by the following code:
<?php
function myModule_menu() { // add this callback to your function
$items['gsf/%/%/%'] = array(
'title' => t('in a moment'),
'description' => t(''),
'page callback' => 'get_styled_file',
'access arguments' => array('access content'),
'page arguments' => array(1,2,3),
'type' => MENU_CALLBACK,
);
return $items;
}
function get_styled_file($filename,$filepath,$style_name){ // get file details and make a file download event
$filename = rawurldecode($filename);
$filepath = rawurldecode($filepath);
$style_name = rawurldecode($style_name);
header('Content-type: image/jpeg');
header('Content-Disposition: attachment; filename="' . str_replace(' ', '_', $filename) . '_' . $style_name . '"');
readfile(file_create_url(image_style_path($style_name, $filepath)));
exit ();
return ('');
}
?>The link of that file download has to be like following:
<?php
print l('1280 x 720',
'gsf/' . rawurlencode($row->node_title) . '/' . rawurlencode($output) . '/' . rawurlencode('wall_1280x720'),
array('attributes' => array('title' => '1280 x 720 wallpaper', 'target' => '_blank'))
);
where: 1280 x 720 = link name in <a>here</a>
gsf = menu callback
rawurlencode($row->node_title) = filename under which it will be saved as
rawurlencode($output) = path to the file
rawurlencode('wall_1280x720') = image style
?>When clicking such link, the user will not get the new image in separate window but an Save as dialog to store the file with the preset filename. While using only image styles for various image resing, the new images will have the same image name. For instance if you resize an image with size 1440x900, each file will have the same filename like file_1440_900 (even if it will have smaller resolution as the filename points out) and only the path to them will be different. With the provided code, you can adjust final filename, style name and the whole dialog is done as Save as not only an new window with the scaled image.
There was a bunch of animations done for different pages. Each of them is stored within one file that you can have a look at: http://unternehmen.christ.de/sites/all/themes/christ/js/animations.js.
Later on, the customer requested special handling for Open graph meta tags for each page. The difficult thing at this was that some content didn't had a teaser image field (views and panels for instance) which could be used as Facebook image at sharing.
ONE HUGE FEATURE/BUG OF THE FACEBOOK SHARE IS THAT YOU SHOULDN'T USE LANDSCAPE IMAGES ONLY PORTRAIT IMAGES, IN SIZE 200px. I've tested 4 hours and searched for the failure where I've used a landscape image of 200x40px image. You can imagine how much happy I was when I realized what was wrong there.
This feature of site specific Facebook OG meta tags is handled by the OG Meta module, posted on drupal.org. This module is handling through an hook_init if the actual page is addet to the module table and if yes, it adds all tags that was preset for that page.
That would be all interesting about the project developing. In case that you mentioned some specialties that you would like to have explained, let us know at web@brandmarke.de.
