This is a new one for me. I upgraded a Drupal site from 6.20 to 6.22. After the core upgrade, the block visibility settings are all goofed up. Quite a few that were enabled prior to the upgrade are now disabled. Additionally, the "Page specific visibility settings" are missing for those blocks.
One other clue in this mystery is that, on the main block admin page (/admin/build/block), my three active themes are in a different order. I'm not sure whether that's related, but I've never seen it before.
I do upgrades on a staging server, so my production site is still intact. For now, I'm going to restore the blocks, comparing the prod with staging settings. I'll see if that restores it to fully functional. Regardless, it makes me nervous. I saw no errors or warning during upgrade.
FYI, my general order for doing the upgrade was:
Empty staging site files and dbase.
Take production site offline.
Copy entire prod site to staging.
Dump prod dbase, restore to staging dbase.
Disable all non-core modules. Switch to core theme (Garland).
Upload and expand drupal-6.22.
Move 'sites' directory from old to new.
Run /update.php.
Enable necessary non-core modules.
Run /update.php.
Switch back to custom theme.
Bam, lots of blocks disabled.
This is a bug. See http://drupal.org/node/1173012
Related
I'm building a site in drupal 8, and I pushed my code from local to our development box, and on the development box, the Admin Primary Tabs have completely disappeared. Everywhere. The following is a screenshot of the issue.
The code is version controlled (git), and the databases are identical. There are no outstanding configuration changes to synchronize either. I'm pulling my hair out trying to figure out what the issue is. Is there a settings somewhere I'm missing? I've tried logging out, clearing the cache, different browser. Nothing. I wanted to get a second option before submitting an issue report on drupal.org.
#see Where are the primary and secondary tab blocks?
You probably installed the minimal profile. And although these blocks are part of the Seven theme they only get installed in the standard profile. Sounds a like a bug. As they rather should get installed during the installation of the theme instead of during the profile installation.
Try this:
Use Drush or Drupal console or the built-in Configuration
Synchronisation to export your current configuration. Then copy the
config files...
core/profiles/standard/config/install/block.block.seven_local_actions.yml
core/profiles/standard/config/install/block.block.seven_page_title.yml
core/profiles/standard/config/install/block.block.seven_primary_local_tasks.yml
core/profiles/standard/config/install/block.block.seven_secondary_local_tasks.yml
... into your config folder - which is probably
/sites/default/files/config_[hashcode]/sync/. Then do a config import
(using one of those 3 tools above).
I Don't know why the configuration are identical when they shouldn't, but I think that the admin theme does not have the "Primary tabs" blocks in header, you can check your production env Block layout and see if infact the "Primary tabs" block is there (admin/structure/block/list/seven).
Rebuilding the cache on the development server fixed the issue.
I created my own theme (not diazo) the classic way via terminal - I used most of the sunburst parts and redesigned them.
The problem is on my local computer and a vanilla plone 4.16 install everything works fine but on the server the theme uses parts for e.g. the navtree.css (in my theme empty) that seems to be part of the classic plone theme and I really don't know why.
Any ideas?
This means the installation on your local machine differs from the one the server.
I only thing I could imagine with the given informations is, that you have a different theme active.
Go to the ZMI (plone root) -> portal_skins -> Properties (Tab).
Check which theme is active.
I guess in your case on the local machine it's sunburst and on the server it's Plone theme classic.
Please provide more informations if this is not the case.
I'm in charge of a website developped with symfony. This website is in prod.
I would like to know how to reinstall the front-end console, because im completely blinded in my task.
I suspect you're talking about the "Web Debug Toolbar":
You can control the visibility of the Web Debug Toolbar in the settings.yml. Set the web_debug parameter to true for the environment you're using. After clearing the cache with symfony cc the toolbar should be visible.
But be warned: enabling the toolbar, will make this visible to all visitors! You probably don't want this!
So depending on your problem I'd first go for enabling logging in production, and analyze the logfiles. If that doesn't solve your issue, copy the frontend_dev.php file to your production server, update it's IP to match your own, and set the environment to test. Next, set the web_debug property in test to true. Clear the cache, and navigate to this scriptfile. This way you can test, while normal users can't access the debug bar.
I'm developing a site in Drupal 6, and I'm going mad trying to work out why pages (specifically pages containing views), I'm working on locally are caching content instead refreshing the contents of the page, and that of linked js files, I'm relying on for making a mashup - is there a checklist I can check against to be sure I'm not missing when trying to deactivate caching?
These are the steps I'm taking:
On the server:
set the site to rebuild the theme on each load
cleared cache using drush (as in drush #dev cc all`) on each page load
checked that the json output from a view isn't caching
disabled any css or js caching in admin/settings/performance
On Firefox/firebug
using the web developer extension, disabled the cache
been refreshing the site using shift-F5 to force a clear of the cache
I'm not using varnish or memcached, nor any other caching modules like boost - it's straight Apache-PHP through to Drupal and MySQL.
What am I missing here?
The three things you need to do are:
Go to Site Configuration -> Performance:
Set the following options, and click Save configuration:
Caching mode: Disabled
Minimum cache lifetime: none
Page compression: Disabled
Block cache: Disabled
Optimize CSS files: Disabled
Optimize JavaScript files: Disabled
Click Clear cached data.
Go to Site building -> Views -> Tools:
Check Disable views data caching and click Save configuration.
Click Clear Views' cache.
Install the Devel module, and go to Site Configuration -> Devel settings:
Check Rebuild the theme registry on every page load and click Save configuration.
This will make sure all registries and caches except for the menu router will be rebuilt on every page, effectively preventing caching in practice.
If you really need the menu router to be rebuilt on every page (it's completely unnecessary, as you only need to worry about it when you change your implementation for hook_menu() or hook_menu_alter()), you could add menu_rebuild() to hook_init() in a custom module:
function mymodule_init() {
menu_rebuild();
}
First you don't need to do drastic things like clear cache using drush #dev cc all on each page load. Also you really don't need to have the theme registry get built on every page load unless you're doing some theme development
Make sure that page caching is set to disabled at /admin/settings/performance
Make sure you don't have some funny .htaccess rules in your drupal site and your .htaccess is the default one that comes with drupal. You might want to make sure the headers for html files generated by Drupal have an expiry in the past and the html has no-cache in the header.You have already clarified you're not using boost, varnish, memcached. It might be a good idea to make sure mod_expires apache module is enabled also.
Make sure in each view under Basic Settings Caching is set to None [I suspect this might be a source of your views not updating]
Are you using windows? If so its not the best environment for apache + PHP and I'll recommend you install Ubuntu 9.10 or an earlier in VirtualBox (Recommending Ubuntu 9.10 or earlier as it has PHP 5.2. PHP 5.3 is not very well supported by Drupal). You can use the seamless mode -- its really very cool.
I'm TEN pages from finishing Using Drupal and I'm stuck. I turned on the Theme Info module to aid in theme customization. However, I can no longer access the admin>>modules page to turn on/off modules (including the Theme Info module). It brings up this white error page that says it tried to access about twice as much memory as is allowed. I could reinstall Drupal, but it'd be pretty lame if that's the only solution.
Any help would be greatly appreciated!
-Landon
Two options.
Remove the 'Devel' module from your modules directory entirely. Reload the page. Voila! No Theme Info module. Downside: If you drag the module back in, it will still be enabled.
Open PHPMyAdmin (if you're using MAMP, WAMP, or a server that has it installed) and run the following query: UPDATE system SET status = 0 WHERE name = 'devel_themer';
Those should work to disable any module "in a pinch." You can also edit the php.ini file in your MAMP/WAMP configuration to give it more memory temporarily, though that trick won't work if you're running on a shared host that doesn't recognize php.ini changes.
First apply Eaton's suggestion (I prefer the second one).
Then increase memory_limit in your php.ini config (usually /etc/php5/apache2/php.ini). A WSOD for just that module means you really don't have enough RAM per script for anything serious: most configurations these days needs 32M at least.