So, I was getting the
"dbModel read resource does not implement Zend_Db_Adapter_Abstract"
error when I moved my install to a staging environment... and could not figure out what the problem was.
So, I checked the $connConfig object in app/code/core/Mage/Core/Model/Resource.php
What I discovered is that the object is created 119 times (?!) in the home page creation, and that 81 times it is false and 38 times it is the correct object.
Is this typical? Are there many times where the connection is set without db credentials for some reason? Or... is this my problem?
The answer is yes, there are many times when the db connection object is called with no data and it returns bool(false)... it's just fine.
...for those of you coming here trying to figure out:
dbModel read resource does not implement Zend_Db_Adapter_Abstract
My issue was a module (FishPig::Wordpress) which called a missing external database. The block which was being created was obvious in the debug trace. I just had to disable the createBlock-> call in a template file, or, eventually, install the external db :P
Related
Jus tried to log in to my web admin and got this error:
Fatal error: Cannot redeclare oceanwp_webfonts_enqueue() (previously declared in /home/customer/www/ozdistributorsusa.com/public_html/wp-content/plugins/ocean-extra/includes/compatibility/ocean.php:94) in /home/customer/www/ozdistributorsusa.com/public_html/wp-content/themes/oceanwp/inc/customizer/controls/typography/webfonts.php on line 128
I can't get acces to the actual site either, any suggestions?
To fix it I manually commented the following functions in /wp-content/plugins/ocean-extra/includes/compatibility/ocean.php:
oceanwp_webfonts_enqueue()
ocean_get_google_font_css()
oceanwp_get_local_webfonts_data_dir()
oceanwp_get_local_webfonts_css_data_dir()
It was a "bad" update, which is now already fixed in 2.0.4 (https://wordpress.org/plugins/ocean-extra/#developers)
After commenting you can update that plugin via the panel or alternatively you can manually update it by removing the folder /wp-content/plugins/ocean-extra/ and uploading again the plugin.
I had the same problem, I got access by changing the theme via in the Database (VIA PHPmyAdmin) for one of the ones that comes by default (like twentytwenty).
I installed a new theme but the whole thing seems unstable still. If nothing better comes up I'm starting a fresh install.
oceanwp_webfonts_enqueue() function declare more than one. this function may be used in loop.
I receive an error when going in backend Catalog->Categories:
Fatal error: Method
Magento\Ui\TemplateEngine\Xhtml\Result::__toString() must not throw an
exception, caught Error: Call to a member function getOptionArray() on
null in
/home/hubert09/domains/domadeco.com/public_html/vendor/magento/module-ui/Component/Wrapper/UiComponent.php
on line 0
I found it after upgrade Magento from 2.2.0-rc to 2.2.5
thanks to magento profiler i found the problem is in:
/vendor/magento/module-catalog/view/adminhtml/templates/catalog/category/edit/assign_products.phtml
$block->getGridHtml();
that line generate problems
=======SOLVED=========
problem caused by 3th part module Oneleek_DraggableProducts. On 2.2.5 it doesnt work. Turn off that module solve the problem.
IF You migrated M1 to M2 then you are facing something below error during cmd execution The store that was requested wasn't found. Verify the store and try again.
please
don't change in vendor
module-store files :
/vendor/magento/module-store/Model/StoreManager.php or
/vendor/magento/module-store/Model/StoreRepository.php
just simply apply below steps:
I just recently came across this same situation after migrating from Magento 1.9.3.8 to 2.3.0 and hope my answer can be of assistance. The problem came from deleting multiple stores 96 of them to be exact. I tried all the other answers here but was still getting the same error.
The fix for me was removing the old store data from inside of the "core_config_data". The problem is that when the Magento is loading the run time configuration data it is finding the old stores and trying to resolve them. Before cleaning the data from the database I HIGHLY recommend you run the SELECT query below to make sure you delete the correct stores.
SELECT * FROM core_config_data WHERE scope = 'stores';
WARNING: MAKE SURE TO BACKUP YOUR DATABASE BEFORE RUNNING THIS!
DELETE FROM core_config_data WHERE scope_id != 1 AND scope = 'stores';
Now execute all magento commands you can see the "The store that was requested wasn't found. Verify the store and try again" fixed by query
Fatal error: Method
Magento\Ui\TemplateEngine\Xhtml\Result::__toString() must not throw an
exception in
C:\wamp64\www\mage2\vendor\magento\module-ui\Component\Wrapper\UiComponent.php
on line 0
Now check your admin above fatal error also solved blahhh... blahh...
(Note fatal error_Magento\Ui\TemplateEngine\Xhtml\Result::__toString()
depedent store module so don't change module-store vendor otherwise
admin side grid/list catalog you can'not see proper data)
We have inherited a magento (CE 1.8.1.0) installation that is showing the following error on a Friday morning on opening the product page:
Fatal error: Call to a member function setType() on a non-object in /data/www.walls.pk/public_html/app/code/core/Mage/Catalog/Model/Resource/Product/Attribute/Collection.php on line 54
There have been no changes to the code on the server that was running fine for the last 6 months.
Can there be a server related or configuration related change (i am thinking from the hosting company) or a version upgrade that causes such an issue ?
Your core eav entity model is unable to instantiate.
$entityTypeId = (int)Mage::getModel('eav/entity')->setType(Mage_Catalog_Model_Product::ENTITY)->getTypeId();
Assuming you have a file that exists in:
app\code\core\Mage\Eav\Model\Entity.php
Clear all caches and delete any cache folders in
root/var/
Run Magento's database fix utility.
Post your
root/var/log/exception.log
and
system.log
contents ( Enable logs if they're empty ).
Check your apache logs for detailed info.
I moved the installation to a different server. I updated the configfile in the var/ directory and the banners are served, but the admin interface is not working.
i get the error:
A fatal error occurred OpenX can't connect to the database. Because of
this it isn't possible to use the administrator interface
i cleaned the cache directory in var but then i get
PHP Fatal error: Call to undefined method MDB2_Error::quoteIdentifier() in /[path]/opx/lib/OA/Upgrade/VersionController.php on line 50
I dont know which version this is, but it looks like its at least 2 years old.
Is there any special cache in place im not aware of?
Any help on this would be much appreciated.
Mental note,.. if you have the db on a different server then openx it does not matter if you set the host to the ip of the db server and the port.. as long if you not set protocol=protocol !!!
this is by far the most stupidest thing i have ever seen, there is no need for a protocol config, as php always uses the socket if you set "localhost".
It's not easy to tell exactly what's wrong here, but one can make a good guess:
As we can see from the error message, there is an object in your code that doesn't implement the method quoteIdentifier().
There are mainly two possible reasons for this: Either we're calling an older or newer version of the same Class instance which doesn't implement the method. Maybe because it's deprecated or who knows. Or the object simply isn't of the expected type.
Lo and behold, if we look for an MDB2 related class that DOES implement this method, it's the class MDB2. Not MDB2_Error! So now we know the reason for the error, it's time to speculate about the root cause.
Connecting to a database with MDB2 works roughly like this:
$mdb2 =& MDB2::connect('pgsql://usr:pw#localhost/dbnam');
if (PEAR::isError($mdb2)) {
die($mdb2->getMessage());
}
There it is. We can see that $mdb2 can actually be of type MDB2_Error, in case connecting goes wrong for some reason. So that is the cause: Your code cannot connect to the DB for some reason. So the next obvious step should be checking if your db user has the correct rights and is using the correct password. I am 100% sure your admin backend doesn't use the right credentials.
I am using php-ldap to manage posix accounts on a linux machine. I am able to search the database in php. And I am able to add users via the command line "ldapadd". However, when I try to add a user via PHP ldap_add, I get an "Object class violation" error (errno 65).
I have tried everything I can think of, but the error has not changed. I have even looked to see if there is an alternative to php-ldap, but have not found one.
The problem is when I look up that error in the general LDAP guide, it says "This error is returned with the entry to be added or the entry as modified violates the object class schema rules. Normally additional information is returned the error detailing the violation." And then it lists 8 possible causes.
I need this more in depth error, but cannot find it. ldap_error was also no help. Any ideas how to dig deaper here?
I figured out how to dig deeper. I am using Ubuntu which was dumping logs to /var/log/{debug,syslog}
In order to get more info I had to increase the log level to 424 in /etc/ldap/slapd.d/cn=config.ldif
Then I was able to see the error in the logs which told me what I was doing wrong... using a dc attribute with an inetOrgPerson objectClass.
Thanks.
Object class violation always means the object you created violated the expectations of the schema.
slapd provides a metric ton of logging if you simply set the debug level to some arbitarily high number.
PosixAccount (the class that is needed for Linux users) has some mandatory attributes. You must provide in the same operation the:
uid
uidNumber
gidNumber
homeDirectory
Perhaps in one approach you are, one you are not?
A comment under ldap_error documentation says that to obtain additional info you can call this:
ldap_get_option($conn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $err);
// $err now contains the additional info
We had the same problems, so we used the following bash command:
sudo tail -f syslog |grep slapd
So you will have an real time window to show you the detail reactions on your LDAP manipulations.