Wednesday, August 20, 2014

Drupal - Omega 4.x - layouts - how to create a layout and add a sidebar (or anything)

Lets start with a giant disclaimer - my lawyer advised me thus, to always start with a disclaimer, even if I am just entering a supermarket or visiting a friend for a coffee:
I don't know if all here under is the correct way to proceed.
Adding a layout as shown in the leveltuts tutorials did not work. But I  probably just forgot a step, multiple times, or multiple steps at different times in the process. Anyway, I decided to do some low level cortex manipulation and lo and behold, that worked.
Low level cortex being simple copy-paste and renaming magic.

I wanted a layout with an extra region in it, and it seems that the best way to do that is to add a layout to your omega subtheme. As I am still novicing into the omega 4.x sass setup, I could be totally wrong on this. 


Well, anyhow, here my cookbook:
1. Create  (if not already there) a folder 'layouts' in your omega subtheme folder
(So in my case the subtheme is called rli2015 and the layouts folder in /sites/all/themes/rli2015/layouts)
2. copy the folder simple from your omega base theme to the layouts folder you just created (sites/all/themes/omega/omega/layouts/simple)
3. Rename this folder to what you wanna call your layout.
I called it allpages as I wanted to create a layout I can use over the whole site
3.1 rename the folder to your layout name. In this aexample allpages.
3.2 rename the file simple.pages.inc to allpages.layout.inc.
3.3 rename the file simple-layout.tpl.php to allpages-layout.tpl.php.
3.4 In the allpages.layout.inc change:
3.4.1 name=allpages
3.4.2 description = whatever text you want here
3.4.3 preview= allpages.png (if you want to make an image for this layout, you can also leave it out)
3.4.4 template=allpages-layout
(has to be what you named your tpl file under 3.3)
3.4.5 Stylesheets (you can leave this one out, or simply add an empty one for later use)

; Stylesheets 
stylesheets[all][] = css/layouts/allpages/allpages.layout.css
3.4.6 Add a region under the regions section

; Regions
regions[branding]       = Branding
regions[header]         = Header
regions[navigation]     = Navigation bar
regions[highlighted]    = Highlighted
regions[help]           = Help
regions[content]        = Content
regions[sidebar_first]  = First sidebar
regions[sidebar_second] = Second sidebar
regions[sidebar_third] = Third sidebar
regions[footer]         = Footer
3.5 Also add this region to your inc file under your subtheme itself, in my case rli2015.inc
regions[sidebar_third] = Third sidebar
3.6 In your tpl file (allpages-layout.tpl.php) add the region you just added where you want it rendered

<?php print render($page['sidebar_third']); ?>
NB! If there is no content in the region, the region will not be rendered
3.7 Copy the omega/sass/layouts/simple folder to your custom theme sass layouts folder
3.7.1 Rename simple to allpages
3.7.2  Rename simple.layout.scss to allpages.layout.scss (has to be the same as the one you declared under 3.4.5)
3.7.3 Strip it of all its content.
4. Go to admin/config/development/performance.
5. Clear all caches.
6. Go to appearance.
7. Choose the settings of your subtheme.
(in my case admin/appearance/settings/rli2015)
8. Enable layout extensions.
9. Select your custom layout and save the configuration.

After that you have a html output with your extra third sidebar (providing you've added content to that sidebar....)

If you have guard (bundle exec guard) running on your subtheme directory the css file should be automatically created under /sites/all/themes/rli2015/css/layouts/allpages.
If not, add the allpages.layout.css file by hand.

NB! GUARD!
I had the problem that guard (bundle exec guard)
stopped working. It simply did not compile.
Dunno why...
Instead of that I ran compass watch multiple times in the same directory, stopping it with ctrl-c. And after some iterations of that I got messages about changes made. And after that, bundle exec guard also ran again. Dunno why....


.




Friday, August 1, 2014

Drupal 7 - Omega 4.x with Sass - how to add a css to the theme

(this is a post under construction, more or less. I am digging into the omega4 -Sass - theming setup framework. Just rather pissed off by spending two whole days on installing RVM - one of the prerequisites for using Sass - on my mac. Will write a blog about that process, when I don't feel the need for strong langiuage anymore. This is just a post about simple tasks you wnat to perform and which nonody seems to want to add to the documentation. Probably because only fools like me don't know how to perform these simple tasks....)
DPMS Panther LRT-SASS 7.62 NATO



This post supposes you have an omega 4 subtheme installed and the Sass environment set up and you have the guard running on your subtheme folder (bundle exec guard)
(see f.i. http://www.code.binarybrand.com/index.php?title=Omega_4)


1. Open your subtheme info file (in this example my subtheme is called rli2015, so we open  rli2015.info)
2. Add a line in the stylesheets section
 stylesheets[all][] = css/rli2015.mobile.css
3. navigatie to your sass folder (in this example themes/rli2015/sass) and add a file
rli2015.mobile.scss
4. Imediately a file rli2015.mobile.css will me generated in your css folder
5. This css file will also be added to your rendered page


Sunday, July 27, 2014

Drupal - Got error 28 from storage engine query

So I had one site with suddenly error 28.

Warning: Got error 28 from storage engine query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta LEFT JOIN i18n_blocks i18n ON (b.module = i18n.module AND b.delta = i18n.delta) WHERE (i18n.language ='nl' OR i18n.language ='' OR i18n.language IS NULL) AND ( b.theme = 'seven' AND b.status = 1 AND (r.rid IN (2,4) OR r.rid IS NULL) )ORDER BY b.region, b.weight, b.module in /var/hosting/sobibor/longshadowofsobibor.com/includes/database.mysql.inc on line 148

As of the site contents I usually first suspect a hacker with extreme right wing sympathies to have destroyed part of the site.
But the issue was very simple and unbiased: Not enough diskspace!


Right wing disk thrower


Drupal 6 to Drupal 7 migration of Audiofields: a missing filefields problem

During a recent D6 to D7 upgrade I got stuck on an irritating problem. Although the filefield module has been included in D7 core, during the migrate fields action the system kept presenting me with the impossibility to migrate filefields from the d6 definitions.

PROBLEM

  • Missing field module: 'filefield'. This field cannot be migrated.
  • Missing formatter: The 'hidden' formatter used in 1 view modes for the field_advies_audio field is not available, these displays will be reset to the default formatter.

    The reason for this problem is that the field has a widget_type audiofield_widget and a widgetmodule audiofield. So I naturally tried to upgrade the audiofield module, but this does not solve the problem. CCK migration simply refuses to migrate these fields. Dunno why exactly.  (Instead of Missing field module: 'filefield'. This field cannot be migrated. a better error message would be: Won't do audiofields. Don't fucking like them. Sue me.)

  • Whaaaat??


    SOLUTION

    Manually change the widget_type to filefield_widget and the widget_module to filefield. You can do this via phpmyadmin for instance. Or to do this for the multiple audiofield we've defined, run this query

    update {content_node_field_instance}
       set widget_type = 'filefield_widget', widget_module = 'filefield'
              where widget_module = 'audiofield';

    If you run it directly use the table name with prefix. The above you can run in Devel.

    I will post here lateron how to adress the presentation in the final upgraded site.


    Tuesday, April 8, 2014

    Drupal - cron memory exhausted trails and tribulations

    Having a Cron job
    So, sometimes you simply miss a cron fail. That happens. Your client calls:
    Hey, the notifications stopped.
    New pages don't show up in the search results.
    Collections not getting indexed.
    A service is down.
    Whatever!

    And I always forget how to solve it. I just rumble along. Sometimes I increase the memory limit, the execution times never works (is hard coded in common inc I believe to be 240 or something), shut down one of the modules, ini_set this, ini_set that,  prune some tables, pray, curse.....

    I must say I utterly dislike cron fails as they are so terribly boring. So  I wanted to write an eloquent and excellent blog about all my cron resolving adventures, just to add some meaning to this annoying part of my life. But then, opening my development and maintenance logs, I remembered: There is no need for me to write anything.
    If you have a cron problem, simply visit https://drupal.org/node/553430 and tell them I sent you.


    Thursday, March 20, 2014

    Drupal - access denied page after login

    Today I got an access denied page after login, just rerooting me to the login page. I 've got this before, on a number of very different sites. Usually this problem coincides with big other problems in the website concerned, so you really can do without this annoying access problem.
    There can be an infinite number of causes: Crashed sessions table, changes in apache, php upgrades, butterflies in Australia....
    Here is my short track to quickly regain access to the site:


    Solution 1
    Truncate the sessions table and then try again

    It is perfectly save to truncate the sessions table although all currently logged in users are then logged out.  The sessions table keeps track of all user sessions on your site. It has an entry for every user/browser combination that's logged in to your site. (Logging in from firefox and from chrome creates two entries in this table, and the same goes for logging in from different devices)

    Solution 2
    Add cookie domain setting to your settings.php file, like this
    $cookie_domain = '.mydomain.ext';
    And then try again

    (see also https://drupal.org/node/1005570)


    Solution 3
    When your sessions table is crashed, simply repair table and try again


    Solution 4
    Find a religion that suits you bests and make an offering to the God or Gods who are proclaimed to be most helpful to developers by this chosen religion.....


    Drupal - unable to overwrite the settings.php

    The funny thing about drupal is it protects your files and permissions automatically. But sometimes I feel like a pilot in a plane where I do not know some of the automation.
    For instance, sometimes you want to overwrite the settings.php file and you do not have the permissions as the FTP user. Here is first a simple set of steps how to proceed.

    Problem: 
    You want to make changes to settings.php but are not allowed to overwrite.

    Cause:
    Drupal automatically sets the following permissions on your default folder and on your settings.php therein

    dr-xr-xr-x 3 {user} {group} 4096 Mar 20 12:31 default
    -r-xr-xr-x  1 {user} {group} 10516 Mar 20 10:27 settings.php


    The user being your ftp user then is not allowed to write into the default folder, nor to overwrite the settings.php file.
    Which is good, of course, but we temporarily want to be bad.


    Solution:
    What you want is to change the permissions, overwrite settings.php, and then reset the permissions to what they where.

    1. login to your server shell and navigate to your site
    cd /var/www/vhosts/domain.ext/sites
    2. change the permissions of the default folder
    sudo chmod a+w default
    3. enter the default directory
    cd default
    4. change permissions of your settings.php (oooow, spooky...)
    sudo chmod 777 settings.php
    5. Now overwrite the settings.php with your FTP program.6. To restore the permissions of the default folder and the settings.php file just login to your site, go to administer -> reports -> status report

    admin/reports/status
    7. running ls -l in your terminal will show you that all permissions are magically restored. Hail Drupal.

    Step 6 is maybe like a braindead way of restoring the permissions, but it is the good way of doing this, let drupal handle this stuff, and you point your brain to problems that are interesting on a human level....