[SOLVED][Drupal 6][Drupal Panels] Cannot control styles after upgrading Panels
https://www.zyxware.com/sites/default/files/styles/user_image/public/pictures/Z_ribbon.png?itok=va3zzVQA
BY webmaster
6 years ago
Drupal-6
0
comments comment

Many Drupal 6 users have reported that they could no longer control styles after upgrading the Panels module in their Drupal installation. If you are facing the same issue in your Drupal site then read on to find out the solution.

Currently the only solution is to patch the Panels module with the following patch. http://drupal.org/files/1412158-administer-panels-styles-d6.patch or wait for a new release with the commited patch

Hope that helps.

The easiest way to solve a Drupal issue is to hand it to the Drupal experts. We can provide a wide range of Drupal services to help you maintain and manage your Drupal websites. Get in touch with us to know more.


RELATED ARTICLE

more_horiz
close

on 10th November 2009 / by webmaster
Drupal allows very fine grained control over how content is presented to the end user. The presentation layer is abstracted beautifully and cleanly designed hooks allows for moving data from the logic layer to the presentation layer. The template file that handles the basic page layout of every drupal site is page.tpl.php and the different regions available for a given theme are all available as HTML elements in page.tpl.php. Another important template file is node.tpl.php which decides how nodes are presented to the end user. Normally the content of nodes go into regions inside page.tpl.php and so does blocks and panels. But what if you want to have regions inside the display area of nodes? What if you want to use blocks to display content inside nodes? The answer is simple - template preprocess is the key. First let us define the region in the theme info file. Open the info file in your theme folder. If no regions[] are defined you will have define all the default regions in the info file explicitly if you want to add new custom regions. Copy and paste the following default regions (as of Drupal 6) into the file regions[left] = Left sidebar regions[right] = Right sidebar regions[content] = Content regions[header] = Header regions[footer] = Footer Now add the declaration of your brand new region. Suppose you plan to use cool_node_region as the name of the region. Note that the right side of the equal sign is the human readable name of the region that you are going to see at admin/build/blocks regions[cool_node_region] = Cool Node Region If you already see regions[] variables, all you have to do is to add your new region. Then go ahead and add your custom region to the node.tpl.php. Create the HTML layout and add the php code to output the content of the region into the layout. In our example you will have to create something like the following somewhere in node.tpl.php <div class="cool-node-region"><?= $cool_node_region; ?></div> Remember to set appropriate css classes and ids so that you can use these to style the content in these regions via your stylesheet and not have to edit your template files again. Create the preprocess_node function in template.php file in your theme folder /** * preprocess hook to add variables to the node.tpl.php */ function theme_preprocess_node(&$variables) { $variables['cool_node_region'] = theme('blocks', 'cool_node_region'); } Rebuild your theme registry and presto you are done. To rebuild your theme registry you can use the devel module or just go to admin/build/themes and save the form without making any changes. You can verify that your new region is active by going to admin/build/blocks. Web Development Drupal Drupal Theming Drupal 6 Drupal Planet Leave a reply Your email address will not be published. Required fields are marker * Gab (not verified) access_time 25 Mar 2019 - 10:03 Thanks for the advice Jake (not verified) access_time 25 Mar 2019 - 10:03 In reply to Great stuff by Gab (not verified) I agree with the entire comment above. Thanks for sharing nice information with us. like your post and all you share with us is up todate and quite informative, i would like to bookmark the page so i can come here again to read you, as you have done a wonderful job. sasha grey (not verified) access_time 25 Mar 2019 - 10:03 Just switched to Drupal and i find it quite confusing at first. However, thanks to your post everything seems much more simple now. vimal joseph (not verified) access_time 25 Mar 2019 - 10:03 You can use, $variables['cool_node_region'] = block_get_blocks_by_region('cool_node_region') in the preprocess_node hook and print render($cool_node_region) in the node.tpl.php Aya Younis (not verified) access_time 25 Mar 2019 - 10:03 Thank you , it was great help :) Pagination Current page 1 Page 2 Next page Next › Last page Last » Add new comment
more_horiz
close

on 19th September 2011 / by webmaster
Upgrading a Drupal site refers to moving it’s database and files from one major version of Drupal to a later one, to take advantage of the newer features and bug fixes that might not be available for the older version. Upgrading a Drupal site is a pretty effective way to make sure that your Drupal site is currently up to date with all the latest security updates and bug fixes. Old versions of Drupal will naturally be unsupported with the arrival of the new releases. The Drupal community has currently stopped supporting the older versions of Drupal like version 4 and 5 and has moved to Drupal 7. However Drupal 6 is more widely supported. Have a look at the steps required to upgrade your Drupal site from an older version to      Drupal 6.      Keeping your Drupal site up-to-date is necessary to make sure that you’re not left behind with a chunk of unsupported code as time passes. Updates and upgrades are necessary to ensure the smooth functioning of your Drupal site. Upgrading a Drupal site refers to moving it’s DB and files from one major version to a later one, to take advantage of newer features and fixes that might not be available for the older one. (On the other hand, updating refers to moving from one minor version to a later one). Many sites still use the 4.x and 5.x versions of Drupal, which the community has officially stopped supporting/maintaining. Drupal.org asks for all these sites to be upgraded to the latest 6.x version to ensure smooth updates and fixes. Here we show you how to upgrade your Drupal 4.x or 5.x based site to version 6.x. The general strategy that we follow would be to update through minor versions till we reach the last available minor version for that major version (that would be 4.7.11 for 4.x, 5.23 for 5.x), and then to upgrade to the next major version’s first minor version. We will continue this process till we reach the last minor version for 6.x. For example, if we are now on Drupal 4.7.1, we update through all 4.x minor versions till 4.7.11, and then upgrade to 5.0. Following that, we update through all 5.x minor versions till 5.23 and then upgrade to 6.0. Then, we move through the 6.x stream till we reach 6.22 which is the latest 6.x minor version as of the date of writing this HOWTO. HOWTO: It would be easier and safer to perform the following updates and upgrades on a local copy of the site. Make sure you have the local LAMP environment as similar as possible, to the production environment (especially PHP - version, extensions). After finishing and verifying locally, you can upload both the DB and files to the production server. Since such an upgrade is a time consuming and risky process, make sure you take backups all along the way. Things would be much saner if you use a VCS such as git. Login as the default admin user (user/1), so that you have permissions to run update.php. Check for all php/drupal function syntax changes/deprecation along the 4.x to 6.x path. Before each update/upgrade stage, check for code hacks and generate patches. Check in the documentation both on drupal.org and inside the module, for patches that might have gone in already, during the version change. After replacing the component core/module/theme, apply and verify those patches one by one, which have not already gone in. Before each update/upgrade, check the existing site components (core, contrib modules, themes) with their original drupal.org versions to find out whether there are any custom code hacks. If present, generate diff patches (diff is a good commandline utility for doing this on linux. MelDiff is a GUI version). Remember to document and maintain patches in a separate folder (patches). You can use the Hacked! and Diff modules for checking for code hacks. (Hacked is a Drupal module that helps you find custom code hacks in the site’s core, contrib modules/themes by comparing the existing code with original copies of their same versions freshly downloaded from Drupal.org. Hacked!, along with Diff, make things much easier). After replacing the code and applying patches (if any), run update.php, followed by cron.php. Check the ‘Recent Logs’ and ‘Status Report’ pages after each update.php run. To handle WSODs, add the following debug code in index.php: error_reporting(E_ALL); ini_set('display_errors', TRUE); ini_set('display_startup_errors', TRUE);  Fix all errors - do not skip. Warnings may be ignored till the final stage. Before each upgrade, disable all non-core stuff (modules and themes). Follow the same procedure as for updates (mentioned above), for the Drupal core. Then upgrade and enable non-core stuff one by one. Before upgrading the theme, make sure you have set the admin theme to a default available core one (such as Garland). Test extensively during each stage of your upgrade. As a general principle, move carefully, keep a descriptive log of your steps (would come automatically if you use a VCS properly), and test extensively. With these simple principles in mind, fill up a snack bowl next to your desk, take a deep breath, and upgrade! Dont have the time/patience to go through all of this, but want somebody knowledgeable to do this for you? We will be glad to take care of this and more! Contact Us Web Development Drupal Drupal 6 Drupal 4 Drupal 5 Drupal Upgrade Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 07th November 2011 / by webmaster
Drupal uses a reasonably powerful mechanism to create, prepare and send emails generated within the system. We maintain two modules related to emails in Drupal - Mail Merge and MailQ (Mail Queue) - and get the opportunity to work with the mail subsystem in Drupal. Here is a brief write-up on how the mail system works in Drupal. The workflow when sending a mail with drupal_mail 1) Module calls drupal_mail drupal_mail($module, $key, $to, $language, $params = array(), $from = NULL, $send = TRUE) The params array should have all the necessary information related to the mail that is to be sent. Do note that the mail is yet to be prepared and that will happen only during hook_mail calls. 2) drupal_mail then calls 2.a) hook_mail of the module calling drupal_mail hook_mail is to be used by the module to copy parameters to $message. The following parameters are already mapped back into $message from drupal_mail $message = array( 'id' => $module .'_'. $key, 'to' => $to, 'from' => isset($from) ? $from : $default_from, 'language' => $language, 'params' => $params, 'subject' => '', 'body' => array() );Drupal mail also sets the following as default headers $headers = array( 'MIME-Version' => '1.0', 'Content-Type' => 'text/plain; charset=UTF-8; format=flowed; delsp=yes', 'Content-Transfer-Encoding' => '8Bit', 'X-Mailer' => 'Drupal' );If default_from is present it is used to set the following headers as well. default_from is either the site_mail if set or from php.ini sendmail_from parameter $headers['From'] = $headers['Sender'] = $headers['Return-Path'] = $headers['Errors-To'] = $default_from; $message['headers'] = $headers;2.b) hook_mail_alter across all modules Other modules can then alter $message as required via the hook_mail_alter call. 3) If $send parameter of drupal_mail is not set to FALSE drupal_mail will call drupal_mail_send 3.a) drupal_mail_send calls drupal_mail_wrapper($message) if smtp_library is set and the module is present. This is how the different modules like mimemail or smtp mail hooks into the mailing system in Drupal. drupal_mail_wrapper is expected to send out the mail and if smpt_library is not set then drupal_mail_send will try to send out the mail using the php mail function. How MailQ works in Drupal by plugging into drupal_mail MailQ is a module designed to allow drupal sites hosted on shared hosting servers distribute the email loads on the system across time to work around the hourly email limits typically set by the hosting providers. MailQ is designed to catch all mails sent by drupal by setting up a drupal_mail_wrapper which will queue all mails during non-cron regular site operations and which will send them out during cron runs. MailQ sets the smtp_library to itself forcing drupal_mail_send to call the drupal_mail_wrapper from mailq during normal operations. Mailq drupal_mail_wrapper will then store all the messages into the database queue and then process these in batches during cron runs by calling drupal_mail_send Web Development Drupal Drupal 6 Drupal Modules Drupal Development Leave a reply Your email address will not be published. Required fields are marker *
Leave a reply
Your email address will not be published. Required fields are marker *

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type='1 A I'> <li> <dl> <dt> <dd> <h2 id='jump-*'> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
The content of this field is kept private and will not be shown publicly.
CAPTCHA This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.