Any time I want to load an external library from inside a class conforming to the Magento module approach. I am always faced with the following error:
require_once(): Failed opening required 'http://example.com/HTML2PDF/tcpdf.php'
Despite that the URL is correct. For example:
class Foo_Bar_AccountController extends Mage_Customer_AccountController
{
public function whatever() {
require_once(Mage::getBaseUrl() . 'HTML2PDF/tcpdf.php');
}
}
Can anyone help understand why I cannot include files this way?
I think I may have figured it out. Not sure why, but I believe Magento somehow doesn't allow including files outside your own module. Anyways this seems to work:
require_once Mage::getModuleDir('', 'Foo_Bar'). DS . 'lib' . DS . 'tcpdf_6_2_11' . DS . 'tcpdf.php';
Just by adding a custom folder inside my module and then calling Magento's Mage::getModuleDir method it works!
If anyone can better explain why this happens then it may help others (myself included) understand better.
Thanks
The Mage::getBaseUrl() function is for URLs, not file paths. So, it will return a string starting with "http://". What you want is Mage::getBaseDir('lib').
The solution you provided works, but typically (and arguably) you should be putting third-party / external PHP scripts in the top-level lib folder. That way all third-party libraries are in one place and you don't have to even call Mage::getModuleDir(). Your folder structure would be:
/magento/
app/
code/
local/
Foo/
Bar/
controllers/
AccountController.php
...
lib/
HTML2PDF/
tcpdf.php
And your controller would be:
<?php
class Foo_Bar_AccountController extends Mage_Customer_AccountController
{
public function whatever() {
require_once(Mage::getBaseDir('lib') . DS . 'HTML2PDF/tcpdf.php');
}
}
What's even better is that when you have files in the base lib, they are included in the autoloader's search for classes. So sometimes you can get away with simply instantiating the class, and the autoloader does the work of finding the correct file to require.
Related
I am building a tiny PHP MVC framework and here is my folder structure
/app
/controllers
/models
/views
/templates
/config
/config.php
/core
/Controller.php
/Router.php
/init.php
/index.php
Inside the index.php which is the front controller I have this code to require the init.php from /app/core/init.php
index.php
<?php
require_once 'app/core/init.php'
$Router = new Router();
$Controller = new Controller();
?>
app/core/init.php
<?php
require_once 'Controller.php';
require_once 'Router.php';
?>
The init.php requires every base controller and classe in /core directory including Controller.php and Router.php and here the index.php also instantiates the classes
Every thing works fine at this point as I tested this by creating the constructor in both Controller.php and Router.php so the code in these two files will be like this
app/core/Controller.php
<?php
class Controller {
public function __construct() {
echo 'OK!';
}
}
?>
app/core/Router.php
<?php
class Router {
public function __construct() {
echo 'OK!';
}
}
?>
inside the index.php it echoes OK! as the classes are instantiates correctly but the problem is that when I want to include the config.php which is located in /app/config/config.php from the Controller.php located in /app/core/Controller.php with this code
<?php
class Controller {
public function __construct() {
require_once '../config/config.php';
}
}
?>
Whenever I do this it returns this error
Controller::include(../config/config.php) [controller.include]: failed to open stream: No such file or directory in C:\AppServ\www\myapp\app\core\Controller.php on line 6
and
Controller::include() [function.include]: Failed opening '../config/config.php' for inclusion (include_path='.;C:\php5\pear') in C:\AppServ\www\myapp\app\core\Controller.php on line 6
I think I used the correct location, I am working from /app/core/Controller.php and want to require /app/config/config.php. I go back one directory using ../
Then why can't I require the file?
From my personal experience using relative file paths will at some point lead to headaches. So I usually use go with an absolute path to the file. This also has the advantage of being a tiny bit faster.
Then if you get an inclusion error at some point it is easier to find the error since you have the whole path available.
To be able to make absolute paths I would recommend you to add a constant in your index.php file (the frontcontroller). Something like the following:
define('ROOT_PATH', realpath(dirname(__FILE__)) . DIRECTORY_SEPARATOR);
Documentation for the functions define(), realpath() and dirname() here.
This defines a constant called ROOT_PATH that references the directory the index.php file is located in and therefore your root directory. At the same time I have appended a directory separator at the end to make it easier to write paths. To use this you would write.
require_once ROOT_PATH . 'config/config.php';
Bonus info
But if you use this approach in your controller.php class you are making it depend in that constant. To remedy this you can pass the root path as a variable in the constructor.
public function __construct($root) {...
And then use it like the following:
public function __construct($root) {
require_once($root . 'config/config.php');
}
Hope this helps.
I don't know what's going on, but require_once() wouldn't throw an error referring to itself as include(), because those are different functions, plus, if that's the whole code, the error line number doesn't match with your require_once() call line either, because it should be 4. Try restarting your webserver and see if it fix something, otherwise you're probably messing something up
While AnotherGuy already gave a proper solution, I'd like to add that the behavior displayed by PHP is actually really quite weird. I set up a little include tree where script A includes B which includes C (all in seperate directories), but B will only include C if I specify a path relative to A, even though the _FILE__ constant at this point shows the path for B. I guess the calling script referred to in the documentation isn't the script calling this function as I'd expect, but rather the script initially served for the request.
I'll wholeheartedly agree with just not using relatively paths, but after years of PHP tinkering it's nice that it just never ceases to surprise to me.
I understand how to register autoloaders and even how to create one, that's no issue at all. How ever the main issue is - how do you have two auto loaders running side by side for something like:
class project_one_folder_class extends project_two_folder_class{}
You'll notice that the child class belongs to a project which is reaching out and calling the parent class which is locate in a different project.
The way the projects are linked project two's classes are always seen by the auto loader, how ever project one's classes are never seen.
So the way I thought around this was to write two auto loaders and register them because php will look in on then the other. How ever php seems to be looking in only one and not the other.
how would you solve this?
Edit
Project two is parent, Project one is child. This is more expanded question then What was posted on this question.
To better expand this is my class.
class AisisCore_Loader_AutoLoader{
protected static $_instance;
public function get_instance(){
if(null == self::$_instance){
self::$_instance = new self();
}
return self::$_instance;
}
public function reset_instance(){
self::$_instance = null;
}
public function register_auto_loader(){
spl_autoload_register(array($this, 'load_class'));
spl_autoload_register(array($this, 'load_child_class'));
}
public function load_class($class){
$path = str_replace('_', '/', $class);
if(file_exists(get_template_directory() . '/' . $path . '.php')){
require_once(get_template_directory() . '/' . $path . '.php');
}
}
public function load_child_class($class){
$path = str_replace('_', '/', $class);
if(file_exists(get_stylesheet_directory() . '/' . $path . '.php')){
require_once(get_stylesheet_directory() . '/' . $path . '.php');
}
}
}
Currently this class will load anything in the parent project. It will even load parent project objects in the child project. How ever no child object can be loaded using this class as it is not found.
Those familiar with WordPress will instantly say, yes its because you have get_template_directory when you want get_stylesheet_directory How ever - Knowing this - I want to write then two auto loaders, one that will load child projects objects using get_stylesheet_directory and then one that will load parent objects via get_stylesheet_directory so that:
class project_one_folder_class extends project_two_folder_class{}
works and loads, with out error.
This is a little rough, but you actually only need one autoloader that just checks within multiple directories:
abstract class Hakre_Theme_AutoLoader
{
public static $directories;
public static function init()
{
// configure paths
self::$directories = array(
get_template_directory(), // current theme, parent in case of childtheme
get_stylesheet_directory(), // current theme, child in case of childtheme
);
// please double check if you really need to prepend
return spl_autoload_register('Hakre_Theme_AutoLoader::autoload', true, true);
}
public static function autoload($class)
{
$filename = str_replace('_', '/', $class) . '.php';
foreach (self::$directories as $directory) {
$path = $directory . '/' . $filename;
if (is_file($path)) {
require($path);
return; # leave because the class has been loaded
}
}
}
}
Hakre_Theme_AutoLoader::init();
## If you're unsure all worked out properly:
var_dump(Hakre_Theme_AutoLoader::$directories);
This should actually do it, however I've not tested it. See the var_dump, you can debug if the correct directories are registered or not. No need to have multiple callbacks only because you want to check in two directories.
Well, of course you could just look up a second path when the first file_exists returns false - in the very same autoloader.
You can also register a second autoloader for the second path.
PHP docs addresses this:
If there must be multiple autoload functions, spl_autoload_register() allows for this. It effectively creates a queue of autoload functions, and runs through each of them in the order they are defined. By contrast, __autoload() may only be defined once.
Separate the autoloading process!
PHP is working like this: At some point, the code execution stumbles upon a class reference that is not yet loaded. $obj = new project_one_folder_class()
Now the registered autoloader functions are called, starting with the one added first (unless the ones added later are using the "prepend" parameter).
The first (and all subsequent) autoload function gets the name of the class that should be loaded. The function now has the task to decide
Is it it's task to load this class? If not, do nothing, let the other functions try to load it.
If this function is responsible to load the class, try to make up a path and filename out of the known class name, and require this file.
Step 1 is usually solved by looking if the class name to be loaded starts with a certain prefix. In your case, the autoloader responsible for loading classes starting with "project_one_" should NOT try to load any other classes starting with something else.
Step 2 takes place if the autoloader knows that it must perform the autoloading. It now transforms the class name into a relative path and filename, adds the base directory, and then requires the file.
Requiring a file that defines a class which extends another class (or implements interfaces) can then trigger another run of autoloading with any still unknown classes. In your case, the autoload process is started again with the class name "project_two_folder_class". Note that the first autoloader for "project_one_" classes will be called again with this second class name, but it must not do anything, because it does not know how to load these classes. This is up to the autoloader that knows about "project_two_" classes.
Order of registration should not matter for the different autoloaders. If it does, autoloaders misbehave.
Because it is a common pattern to simply transform any underscore characters in class names into DIRECTORY_SEPARATOR, as well as the backslashes from namespaces, add ".php" at the end, and then try to load this file from a defined base directory, the code for two of these autoloaders will be identical, and the problem is reduced to configuring only one autoload function with these two cases: Which prefix should be present, and in which base directory should the file be expected to be, provided that the class name can be transformed into a relative path to the file.
Checking in every case whether the file exists in a certain directory or not is not optimal for performance. You'll end up doing plenty of checks for files that you will be able to know you cannot load by simply looking at the class name.
And by the way: Autoloader functions do not need to be singletons. In fact, your singleton implementation is broken, and useless. Instantiate the autoloader with new, maybe pass some configuration values into the constructor, and call spl_autoload_register(), and you should be done.
You can add more than one loader, just register each function with spl_autoload_register().
procedural style:
spl_autoload_register('loader_function1'));
// your second class location
spl_autoload_register('loader_function2'));
or in a OO style
spl_autoload_register(array($this, 'loader_function1'));
spl_autoload_register(array($this, 'loader_function2'));
However based on your question: you probably can accomplish the same thing by having a more flexible autoloader
see my answer in a different question here:
Class autoloader in wordpress plugin
I have a strange problem I can't figure out. I'm using PEAR to send mail from a PHP page. The Send_Mail class is working (sending mail using SMTP), but I'm getting this strange warning associated with my autoloader.
Warning: include(classes/LOGIN.php)
[<a href='function.include'>function.include</a>]:
failed to open stream: No such file or directory in
C:\xampp\htdocs\mysite\initialize.php on line 46`
In my initialize.php file, I have this:
function autoloader($class) {
include 'classes/' . $class . '.php';
}
spl_autoload_register('autoloader');
And in my header.php file I am loading several PHP classes for the site:
// autoload PHP classes for site
autoloader('Navigation');
autoloader('Validation');
The error referes to a LOGIN class which I don't have. But I searched my entire site folder, including php and found these two lines in C:\xampp\php\PEAR\Net\SMTP.php:
/* These standard authentication methods are always available. */
$this->setAuthMethod('LOGIN', array($this, '_authLogin'), false);
$this->setAuthMethod('PLAIN', array($this, '_authPlain'), false);
When I comment out the line containing LOGIN I get the same warning but for PLAIN and when I comment out both lines, the warnings go away (but then SMTP authentication fails).
Why is this happening?
UPDATE
Here is my new autoloader:
function autoloader($class) {
if (file_exists('classes' . $class . '.php')) {
include 'classes' . $class . '.php';
}
}
When I echo 'classes' . $class . '.php', though, I get this:
classes/.php
And then if I change it back to not use the file_exists it works, but the echo still shows classes/.php
I'm not sure what version of Net_SMTP you're on, but the setAuthMethod function takes as a parameter various different types of structures - method names, classes, objects, callables, etc.
Since PHP is dynamically typed, SMTP.php in Net_SMTP has to do a lot of checking on that object in order to determine what type of object it is. As part of that, it tries to determine if 'LOGIN' is a class name, which is invoking your autoloader.
The solution is to perform a file_exists in your autoloader before trying the include, but of course if your include path is complex in any way you're basically setting yourself up for headaches. Anyone who has dealt with writing a comprehensive autoloader knows your pain.
I reverted back to a simple autoloader and things seem to be working fine:
function autoloader($class) {
include 'classes/' . $class . '.php';
}
spl_autoload_register('autoloader');
Thanks for suggestions.
I'm using Codeigniter 2.1.0.
I'm including the Amazon Web Services SDK in a custom model using require_once APPPATH . "/libraries/aws_sdk/sdk.class.php";
This works well. However when CI decides it later needs to load it's db cache class, it calls (via CI_DB_driver::_cache_init):
if ( ! class_exists('CI_DB_Cache'))
{
if ( ! #include(BASEPATH.'database/DB_cache.php'))
{
return $this->cache_off();
}
}
This triggers the autoload of the AWS SDK (the exact method being CFLoader::autoloader).
I can get around this by telling class_exists not to autoload, as it seems that DB_cache.php is included anyway if class_exists returns false:
if ( ! class_exists('CI_DB_Cache', false))
{
if ( ! #include(BASEPATH.'database/DB_cache.php'))
{
return $this->cache_off();
}
}
This dirty fix works, but obviously only fixes the immediate problem. In general, what is the best way to ensure that CodeIgniter doesn't get confused with the autoload from other libraries?
Please note:
I've read bits and pieces about using spl_autoload_register. It seems that Codeigniter doesn't use this and I'm not sure how I should implement this safely. I would find a solid example of how and where I should implement this most useful (if, of course, this is the solution).
It appears that the AWS SDK already uses spl_autoload_register: spl_autoload_register(array('CFLoader', 'autoloader'));
As you probably know, you don't really want to be modifying the core methods in CI. So, to prevent CI from conflicting with your class, you want to do something very similar to the following:
Leave your folder structure as is, but create a new file outside your aws_sdk folder. Name it something like *Aws_loader* or something that makes sense to you. If you want to autoload the sdk, then in the CI autoloader file, add:
CI Autoload file (application/config/autoload.php):
$autoload['libraries'] = array('Aws_loader');
Your init file:
class CI_Aws_sdk{
// for use with PHP < version 5
/*public function CI_Aws_sdk(){
require dirname(__FILE__) . DIRECTORY_SEPARATOR . "aws_sdk" .DIRECTORY_SEPARATOR . 'sdk.class.php';
}*/
// for use with PHP >= 5
public function __construct(){
require dirname(__FILE__) . DIRECTORY_SEPARATOR . "aws_sdk" .DIRECTORY_SEPARATOR . 'sdk.class.php';
}
}
So your directory structure looks like this now:
application --
config --
...
libraries --
Aws_loader.php
aws_sdk --
sdk.class.php
If you aren't autoloading the sdk, then in your controller, you can do this:
$this->load->library('Aws_loader');
Either way, CI with load the class for you and effectively separate any methods within it and now you can operate within that class just like any other library or model that you've loaded previously, without interfering with CI's methods, similar to this:
$this->Aws_loader->do_something();
You can use the same method for any third party class library or even one that you wrote yourself. A very similar arrangement can be used for models, libraries, helpers and the like.
Hope this helps!
We are finding cases where we get the following 500 error:
File xyz.php does not exist or class "xyz" was not found in the file at () in SF_ROOT_DIR/lib/vendor/Zend/Loader.php line 107 ...
where xyz ==
Memcache (when trying to use symfony cc on the command line)
or
sfDoctrineAdminGenerator (when using an old-ish AdminGenerator-generated CMS page).
We use Propel, but Loader.php is trying to load classes used only for Doctrine.
Currently I am using a filthy hack where I request Loader.php to check if the file is either of these two cases, and if so simply return rather than trying to load it. Obviously, this is unacceptable longer term.
Has anybody encountered this, and how did you solve it?
Edited to add:
We have:
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// for compatibility / remove and enable only the plugins you want
$this->enableAllPluginsExcept(array('sfDoctrinePlugin'));
}
}
And we have a propel.ini file in our top level config directory. This has only started in the past four weeks or so, and we've had a stable build for over a year now. I'm pretty sure Doctrine is totally disabled.
The only thing I can think of is to make sure Doctrine is disabled in your project configuration...
Could this be a conflict between Symfony's autoloader and Zend's? Try adding the following to your ProjectConfiguration.class.php:
set_include_path(sfConfig::get('sf_lib_dir') . '/vendor' . PATH_SEPARATOR . get_include_path());
require_once sfConfig::get('sf_lib_dir').'/vendor/Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
I use Zend Lucene using the above and it works. If that doesn't help, perhaps something in these Zend and Symfony slides may help.
Clear Cache :) And make sure your index.php have the right include file.