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.
Related
I am using phpseclib to do some SFTP stuff. At the moment I can't login, and I am trying to find out why. In the docs, it states I should do something like this
set_include_path(get_include_path() . PATH_SEPARATOR . 'phpseclib');
include 'Net/SFTP.php';
define('NET_SFTP_LOGGING', NET_SFTP_LOG_COMPLEX);
$sftp = new NET_SFTP('***');
if(!$sftp->login('***', '***')) {
print_r($sftp->getSFTPErrors());
}
So, I need to define the type of logging in order to print out the SFTPErrors.
I am doing things differently than the above because I am using composer. So as usual, I load autoload.php. Instead of include, I make use of use e.g.
use phpseclib\Net\SFTP;
I then proceed to do something like the following
define('NET_SFTP_LOGGING', NET_SFTP_LOG_COMPLEX);
$sftp = new SFTP($config::SFTP_SERVER);
if(!$sftp->login($config::SFTP_USER, $config::SFTP_PASSWORD)) {
print_r($sftp->getSFTPErrors());
exit('Login Failed');
}
If I do this however, I get the output
Notice: Use of undefined constant NET_SFTP_LOG_COMPLEX - assumed 'NET_SFTP_LOG_COMPLEX' in ...
Array
(
)
Login Failed
So it appears that with composer, I cant define a constant in the same way, and the print out of the errors produces an empty array.
So, how can I define this constant in my composer project?
Thanks
A few of things.
If you're using the namespaced version of PHP (as evidenced by your use phpseclib\Net\SFTP;) then you're using the 2.0 branch. The documentation on the website is for the 1.0 branch. For the 2.0 branch you need to do as Félix Saparelli suggested - SSH2::LOG_COMPLEX.
That said, logging isn't going to show SFTP errors. Logging shows you the raw packets. Here's an example of what the logs produce:
http://phpseclib.sourceforge.net/ssh/log.txt
You get these logs by doing $ssh->getLogs().
For the errors you don't need to enable anything - it places any errors it receives from the server into an array that it's returning to you. phpseclib does this automatically and this behavior cannot be disabled.
Also, $sftp->getSFTPErrors() is great for SFTP errors but at the login process you might be getting SSH errors and not SFTP errors. You'd get SSH errors by doing $sftp->getErrors(). The thing is... SFTP operates in a higher layer than SSH. SSH won't succeed if TCP/IP can't make a connection and SFTP won't succeed if SSH can't make a connection. So per that you ought to be checking all the layers.
Finally, it's quite possible the failure is happening for reasons for which errors would not be returned. Maybe the server requires compression, which phpseclib doesn't support. eg.
http://www.frostjedi.com/phpbb3/viewtopic.php?p=221481#p221481
I also don't know if you'd get an error if the key or password you were using was simply invalid.
Really, there could be any number of causes for an inability to connect. You could be using selinux which, by default, disables outbound connections from PHP scripts running on port 80, there could be a routing issue, etc (all of these affect fsockopen, but, in all, there are just a lot of potential causes for failure).
Overall, I'd say you're on the right track with the logs. But do $sftp->getLog() instead of $sftp->getSFTPErrors() and then include the logs in your post.
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
I am looking for help with this problem and I hope someone give me that help. The error is the following:
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://example.com/index.php/api/?wsdl' : failed to load external entity "http://example.com/index.php/api/?wsdl" in
/var/www/presentacion/app/code/local/Pengo/Extension/Model/Something.php on line 28
And the code that I'm using to connect to it is something like this:
$this->_soap = new SoapClient(http://example.com/index.php/api/?wsdl);
and there is where it says is the error.
I have been serching in Google, PHP forums, here in StackOverflow and Magento itself but I don't find the solution anywhere.
What I had seen is that the WSDL is never get parsed or loaded as the error says and none of its functions.
I tried connecting like this:
$options['location'] = http://example.com/index.php/api/?wsdl;
$options['uri'] = 'urn:Magento';
$this->_soap = new SoapClient(null, $options);
like this it doesn't dispatch any error like the others but there aren't functions to use, like in the other case it doesnt' load and parse the WSDL.
I am a bit frustrated because I have been developing this like 1 month and now that I am making some tests it shows this message, I had test it when it was really empty and new and it worked fine.
So any help would be appreciated.
Thank you.
Nine times out of ten this error is Magento is telling you it can't load the WSDL file. Magento is telling you this. It's not your local client code that's complaining.
Magento uses the PHP SoapServer object to create its SOAP API. The SoapServer object needs to access the WSDL as well. Try running the following from your server's command line
curl http://example.com/index.php/api/?wsdl
If I'm right, the above will timeout/fail.
Because of some quirks in DNS, it's surprisingly common that a server won't be able to access itself via its domain name. If this is the case, the quickest fix is adding an entry to the server's hosts file. (Talk to your server admin if none of that made sense)
Well after all the things that I test the only one that worked for me, I don't know why but it worked, was doing this in two separate machines. I tried that because I read that somewhere and I just do it and my Magento and Webservice now works perfectly. Whenever I try to do this local it dispatch the same error.
I hope this can help someone in the future and they don't have to knock their head on the wall because of this problem.
Thank you all for your answers and comments.
Alan Storm is right on the Money here!
Make sure that you check your server Hosts File, and that it includes an entry for both domain and www.domain. Espicialy important if you are doing server rewrites.
The following exception is thrown on my server:
Fatal error: Class 'My_Model_Bo_User_Agenda_Doctors' not found in...
Though in localhost everything is working fine.
I checked that everything was correctly uploaded; all the files are present and not corrupted. I also tried to upload several times. So this doesn't seem to be the problem.
Any idea why a class couldn't be found on the server ?
You don't say so in your question, but I suspect that you are developing on windows and hosting on Linux.
Windows is not case sensitive to path names, but Linux is! Check that:-
Doctors.php is not doctors.php
Agenda/ is not agenda/ .etc
Lastly check the class name in the class declaration is correct and correctly cased.
Do not just think to yourself, yes I've done that, go and check them carefully. Believe me, bitter experience has taught me this problem is always due to a trivial oversight like this.
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.