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.
Related
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.
So I am about to add another WP blog, but I'd like to keep it under version control. Then I started thinking, how would that affect my current WP workflow. Based on my limited xp in using WP, when an update is pushed from WP dev team, I see an indication in my admin control panel. From here I can simply click the button, and the changes are implemented behind the scene. This approach is great for a single WP instance outside of version control, but what about more nodes, and in version control?
Some of the WP updates include both code and schema changes, so I can't simply publish the code without also implementing the new schema changes. The best I can figure it is to do the following:
Localize current WP version stored in version control
Download latest (stable) wp files
Extract to local path (created in step 1)
Diff changes (optional)
Commit changes to version control
Log into each server
Put into maintenance mode
Pull latest changes
Implement new schema changes (????)
Test
Take out of maintenance mode
Step 9 is what is tripping me up. Do I do a schema dump from my local (freshly updated) schema, then import that schema for every server (or use provided schema change file if WP included id).
Is there a better approach to this?
---- EDIT 1.20.2014 ----
After further consideration, I wonder if setting up some type of mysql replication would be the way to go? Have one node access with read/write access so it can make changes which are restricted to database only (i.e. de-activating a widget), but have other servers serving up the blog content read from readonly mysql instances which are replicated to. This way only one server is making changes from which the others will pull. During my research I have noticed that some changes like alterations to child theme via functions.php or style.css can be tracked in version control, but other changes like activating/de-activating widgets are purely sql based, which would be impossible to track in version control.
Is there a better approach to this?
Don't touch WP core (do you really need it?)
OR
Hack core only once in order to replace default repository's URL of WP-core with your's and later use system auto-updater with your repository
I am currently building a website using drupal 7.x. Unfortunately I cannot seem to enter the admin/config page. Every time I click on the configuration tab on the administration menu, I only get a blank page. Then I created another sample site. It also has the same problem and I am using WAMP server. I cleared cache and finds no difference. I have searched for similar issues, but could find none. Can someone please tell me what I am doing wrong?
A number of things can cause the White Screen of Death, but the most common things to check:
As suggested above, memory limit may need to be increased.
Have you enabled any modules other than those in Drupal core? Try disabling contributed modules and enable individually until you experience the error, to help you identify which module is causing trouble. If you can't access the modules admin page, you can disable them in the database - the system table has a 'status' field. 1 means enable, 0 is disabled.
Could it be a permissions issue? Check admin access permissions or try logging in as the superuser (user ID 1).
Lots more and discussion here and here.
Finally I got the answer. Increase the max_execution_time in php.ini file. It solves the issue.
A few things to try...
Check your php error log for clues.
Create a simple file that calls phpinfo() and see what your memory_limit is. It may need to be increased.
Try tweaking your php.ini to get it to display an error message instead of a blank page.
I tracked this very issue to l10_update module, once I enable it, admin/config shows the WSOD. Once I disabled it, everything's fine. So:
- unchecking the localization_update module in the "modules" list
- de-installing it from the modules list
- deleting directory sites/all/modules/l10n_update
- and re-installing the module (from the same tar.gz file)
Source: https://www.drupal.org/node/1141160
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
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.