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.
Related
As stated by this solution, the workaround proposed works very well on dev and test SS environments.
The suggested one is to avoid the current bug related to auto-publish files managed via DataObject $owns property.
But since I uploaded my project in production - on live env - the workaround doesn't work anymore.
In my case I'm working on a DataExtension of User model. The rest of implementation follows exactly the above mentioned case - with UploadField.
In production, it seems that the snippet is ignored in its condition. In particular, this is my version:
UserExtension
// AllegatiDownload: many_many File type uploaded with UploadField
public function onAfterWrite()
{
if ($this->owner->AllegatiDownloadID) { // <- This is being ignored in live version
$this->owner->AllegatiDownload()->publishSingle();
}
parent::onAfterWrite();
}
If I try to replace
$this->owner->AllegatiDownloadID
with
$this->owner->AllegatiDownload()
The condition pass, but $this->owner->AllegatiDownload()->publishSingle() returns an untraced 500 exception. Just:
There was been an error
And, as I said, this happens only in production.
Thanks in advance for support.
Today I flushed the project DB in order to upgrade a custom front-end component that interacts with it. Seems that after that flush, the issue being solved. That's pretty strange, because I tried many /dev/build?flush=all before, and nothing happened. Server cache maybe? I don't know. But now the workaround works as expected.
Thanks anyway for the support.
I've finished a web site that runs on my computer and on the old server. The problem is that the old server is dying and my employer wanted to move it to a new server.
When he moved it, one web page shows me an error:
The autoloader expected class "Equips\FrontendBundle\Helper\LDAPHelper" to be defined in file "/var/www/sinfratic_dev/src//Equips/FrontendBundle/Helper/LDAPHelper.php". The file was found but the class was not in it, the class name or namespace probably has a typo.
and it's like "what?" because I haven't done anything of that part (I just worked with another part of the web). And I've checked that file and inside there is the class "LDAPHelper".
I know what a server LDAP is, but I don't know if that problem is because the new server cannot communicate with out LDAP server or it doesn't have all things installed (I've installed ldap-auth-client, ldap-auth-config, libaprutil1-ldap, libldap-2.4-2, libldap2-dev, libnss-ldap, libpam-ldap and php5-ldap; things that were on the old server but not in the new, but it still doesn't work).
Any idea?
Thanks you so much.
EDIT
Thanks for the comment. Here is the header of the file:
<?
namespace Equips\FrontendBundle\Helper;
class LDAPHelper {
Ok, it was PHP and something unexpected.
By default, short_open_tag is off, so this .php could not be readed properly.
Just needed to put it on in php.ini.
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'm using PHP 5.4, and have a PSR-0 class structure similar to the following.
A\Library\Session.php:
namespace A\Library;
class Session { ... }
My\Application\Session.php:
namespace My\Application;
class Session { ... }
My\Application\Facebook.php:
namespace My\Application;
use A\Library\Session;
class Facebook { ... }
When I try to run the application, I get the following error:
Cannot use A\Library\Session as Session because the name is already in use in My\Application\Facebook.php
Even though it's not, at least not in this file. The Facebook.php file declares only the Facebook class, and imports exactly one Session class, the A\Library one.
The only problem I can see is that another Session class exists in the same namespace as the Facebook class, but as it was never imported in the Facebook.php file, I thought it did not matter at all.
Am I wrong (in that case please point to the relevant documentation), or is this a bug?
There is a bug confirmed in PHP that may affect the behavior you see. It is supposed to fatal error, but with opcache enabled, it may still execute flawlessly.
https://bugs.php.net/bug.php?id=66773
If it still concerns you, please vote for the bug.
No, this is not a bug. As mentioned in Using namespaces: Aliasing/Importing
use A\Library\Session;
is the same as:
use A\Library\Session as Session;
So try using something like:
use A\Library\Session as AnotherSessionClassName;
The only problem I can see is that another Session class exists in the
same namespace as the Facebook class, but as it was never imported in
the Facebook.php file, I thought it did not matter at all.
Yes, it does matter. This is why you don't need to "import" classes from the same namespace. If you have conflicting names from different namespaces, you need to alias the class.
namespace My\Application;
use A\Library\Session as ASession; // choose a proper alias name here
class Facebook { ... }
I've read the thread about the issue, but I tested on many PHP versions (php 5.5, 5.6, 7.*, x32, x64, vc11, vc14, vc5). I'm using Laravel with Laragon. But, when I build up the server with php artisan serve (and open the server at http://localhost:8000) I have the problem of "the namespace that some Class was already used" and stuff.
I tested with and without opcache extension and nothing works, then I tested the virtual domain that Laragon provides and... voila, the error just disappeared and now I can work OK. I don't know what was happening, my namespaces were OK, I had an alias but the same code works in many machine without problem (AWS, local, prod, dev, etc) but only in my machine I had the problem just as I described it.
So, if someone is working with Laravel (5.1) and is having this issue, try the virtual host of Laragon.
I've been developing WordPress sites for a long time on my local MAMP server. Now all of a sudden, it won't let me create any new sites. Whenever I set up a new one, instead of running the install script I get:
Fatal error: Cannot redeclare class
wpdb in
/Applications/MAMP/htdocs/[my_site]/wp-includes/wp-db.php
on line 52
This happens with all WordPress versions. I cannot thing of anything that would have caused this. I've done everything short of re-install MAMP. Does anyone have any ideas? I'm desperate at this point..
Check out the include path for php. It's likely that a second instance of wordpress is on the include path and is therefore conflicting with the one you're trying to load. It's also possible that a different package on the include path has a class called wpdb and is therefore causing a conflict.
wpdb is being created again some where, if this happened all of a sudden i suggest that you disable any plugins you've recently added. Or even better do a global find for the term class wpdb and see if that appears within more than 1 file. Also, check your functions.php file for a loop that might be loading wp-db.php more than once.
A workaround fix is to wrap the wpdp class in wp-includes/wp-db.php in the following:
Line 52:
if(class_exists('wpdb') != true)
{
class wpdb {
...
}
}
This solved the install issue- You could probably remove it after that, although it can't hurt to leave it I guess.
Still don't understand why this problem has popped up- If someone has an explanation I'd be eager to hear it.