I moved to a new server with my Drupal 7 site. However, I get the error:
PDOException: cache_clear_all()
SQLSTATE[42S02: Base table or view not found: 1146 Table 'Zadmin_akademi92anka.cache_metatag' doesn't exists:
TRUNCATE {cache_metatag} ; Array( ).
It appears a table was lost in the move. Disabling the module metatag would be a quick fix. If you can't disable that module through the UI then you can do it my setting the status to 0 on the related row in the "system" table in your database.
Just ry to recreate the 'cache_metatag' table, it happend to me too, eventhough I just install a fresh Metatag module. It seems there is some process interupt or install failed when you enable this module, can be the connection or else where on the server side.
All cache table has the same structure, so you can copy the table structure for 'cache_metatag' table from another cache table.
The problem is clearly written in the error message: a table doesn't exit.
Related
"The website encountered an unexpected error. Please try again later." When I went to clear cache in D8 and no further details. I have encountered a similar issue before on another drupal site and in my experience, the "Unexpected error" seems to be a general error message that Drupal gives, while there will likely be a more detailed message.
Thus, to further investigate the issue I enabled logging with $config['system.logging']['error_level'] = 'verbose'; in my settings.php.
Which produced the following upon refreshing the site:
The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Extension\InfoParserException</em>: Missing required keys (core) in modules/contrib/redirect/modules/redirect_404/redirect_404.info.yml in <em class="placeholder">Drupal\Core\Extension InfoParserDynamic->parse()</em> (line <em class="placeholder">29</em> of <em class="placeholder">core/lib/Drupal/Core/Extension/InfoParserDynamic.php</em>). <pre class="backtrace">Drupal\Core\Extension\InfoParser->parse('modules/contrib/redirect/modules/redirect_404/redirect_404.info.yml') (Line: 552)
I understand that sometimes issue come about when one does not clear the Drupal cache. As a result I have tried to flush all caches via the database by truncating the cache tables as the UI is unavailable. Also ran composer install; composer update but to no avail.
I would appreciate any solutions on how to address the issue at hand.
Thanks
I saw this error as well, though on Drupal 8.7.6, after updating the Redirect module (and its submodules). I fixed it by adding core: 8.x to each module's .info.yml file, as was suggested in a similar issue for the Admin Toolbar module.
I then updated Drupal core to version 8.1.1, at which point I had to remove that line – The 'core_version_requirement' constraint (^8.7.7 || ^9) requires the 'core' key not be set – so that may be a temporary measure.
(As an aside, you mentioned clearing cache through the UI and the database, but you can also clear your cache using Drush: https://drushcommands.com/drush-8x/cache/cache-rebuild/)
I am trying to publish Umbraco 4.7.0 site.
when i am trying to publish Node get this error.
Cannot insert the value NULL into column 'id', table 'hedronDB.dbo.cmsPropertyData'; column does not allow nulls. INSERT fails.
And when i see in browser i get "Looks like there's still work to do" this error.
Any help is much appreciated!
I assume you are seeing the error in the database's [umbracoLog] error table?
Have you just migrated your site to a new server? If so, your umbraco.config file may be missing. This is usually why you see the "Looks like ..." message, because nothing has previously been published.
Also, check the permissions on the site to ensure that modify permissions have been given to the correct folders.
If none of these help, one of your doc types or pages may be corrupt, meaning that when a page or pages of a particular doc type are being saved, Umbraco thinks there should be a particular property on the doc type when there isn't.
Check the Umbraco logs in the database [umbracoLogs] table, and see if there is a reference to a particular doc type or page being saved. The solution here would be to recreate the offending doc type, and also recreate the pages from the doc type.
Aside from this, it is always worth checking or raising your issue at our.umbraco.org
Finally, if possible I would very much advise upgrading to the latest version of Umbraco (currently v6.1.2) or at the very least v4.7.2 which is a patched version of the version you are using.
I have just updated a site that is using Drupal and have now experienced the horrible WSOD.
I have searched through Google looking for any sort of solution/error log to help me find and fix the issue but nothing has worked. I have tried adding in the 'display errors' code in the index.php file and looked at the error_log file in the public directory and nothing.
I can not login to the admin page and check any modules as the login page for this is returning a 403 error.
Any suggestions?
Please go to Apache Error log. You will exact error messages there.
The log file's location is different for different OS and versions.
e.g httpd/log/error.log
Maybe your Drupal registry is broken.
Fix this using the registry_rebuild script (this is no module!)
There are times in Drupal 7 when the registry gets hopelessly hosed and you need to rebuild the registry (a list of PHP classes and the files they go with). Sometimes, though, you can't do this regular cache-clear activity because some class is required when the system is trying to bootstrap.
You might get something like:
PHP Fatal error: Class 'EntityAPIControllerExportable' not found in ...sites/all/modules/rules/includes/rules.core.inc on line 11
If this happens when you're trying to run update.php, and happens when you're trying to clear your cache, well, you have some trouble. That's what Registry Rebuild is for.
It also may happen that you've moved some module that Drupal requires to bootstrap, and you get a horrible error. Registry Rebuild will also rebuild the system table to get the modules in the right place so you can bootstrap.
You will need PHP-CLI or drush to run this.
https://drupal.org/project/registry_rebuild
I've started a new Wordpress site, and and trying to import a database form a site I had about 3 years ago.
Whenever I click on import, choose the file and set it away, I get this error:
Error
SQL query:
--
-- Table structure for table `wp_commentmeta`
--
DROP TABLE IF EXISTS `wp_commentmeta` ;
MySQL said:
#1046 - No database selected
I've tried a few fixes such as setting the Do not use auto interrupt to off, unticking allow interruption, setting the compatibility mode and changing the character set but nothing seems to work.
I did import this file into another Wordpress blog about a year ago, so I know it worked then, but it's refusing now.
This is the phpmyadmin version:
Server: 109.68.38.30 via TCP/IP
Server version: 5.1.52
Protocol version: 10
User: DM_7850_dbadmin#webserver1.wwwconfig.net
MySQL charset: UTF-8 Unicode (utf8)
I hope someone will be abel to help here.
try following query to select database and then check
USE database_name;
I have just moved site from online to the local , I have used "authcache, cacherouter" caching module , but restoring site in local there are so many data in the cache table and having problem to download and restore those tables so i just created those tables with blank entries in local and now getting "Access denied" error in all the pages , even i am not able to log in in admin and can not access to the admin section.
I have tried so many solutions available on the net but not get success , Can anyone here help me out on this issue . ?
So much thanks in advance..
Several steps to take:
Are cookies working at all: Do you get a cookie (check your browser) and is the domain in that cookie correct?
Did Drupal insert the session? Check the sessions table in Drupal. For evaluation, empty that table (TRUNCATE sessions) and check again: is a new entry made?
Are there any errors? Check the watchdog (without access to the site, you can either use drush or read the watchdog table.
Does the server or one of its services give you any hints in their log? Check /var/log/mysql* and /var/log/apache/* for starters.
Did you try disabling modules? Disable all modules execpt a few core ones (use Drush, or set the status column in the system table to 0). Is the problem still there? No? Then toggle modules on, one a time, a certain module will introduce the error again.