I have several projects on my host. They have many similarities and I want them to use common node_modules. My folder structure looks something like this:
_CONFIG.php
node_modules/
project1/
index.php
project2/
index.php
project3/
index.php
In all my index.php files, I require_once '../_CONFIG.php' where I've set:
$node_modules = '../node_modules/';
Then in each project, when I need to use a Node module, I have:
<script src="<?= $node_modules; ?>jquery/dist/jquery.min.js"></script>
I do this because I might need to change the path of node_modules. If everything is hardcoded, I'd have a rough time. Let's say I install upgraded node_modules and I want to have a backup. I want to be able to quickly switch between the old and new modules, in case some of the new ones are incompatible with one of my projects.
I have other common things between the projects that I want to be easily configurable via the _CONFIG.php file.
Question
I know that polluting the global scope is not a great thing and that's exactly what I'm doing. Is there a better way to do this? In the same time, I don't want to do a ton of stuff just to output a string in a script tag's src attribute.
What about defining constants? It's quite useful for defining global options, and you do not pollute the global scope at all.
define('NODE_MODULES_DIR', '../node_modules/');
and then later use it there:
<script src="<?= NODE_MODULES_DIR ?>jquery/dist/jquery.min.js"></script>
I'm not aware of a "better" solution.
Keeping configuration outside of your code is the way to go. You put all your connection strings, pwds etc in a config file as suggested by The Twelve-Factor App.
Instead of using global variables, you could add one level of indirection by using a wrapper function that returns values based on a given key-string.
phpdotenv provides these capabilities nicely.
Related
I come from the procedural PHP and am learning OOP with Laravel. What I learned so far is very interesting and will ease my developer's life (it's not my job btw).
So, for all my websites, I am using a slug property for all articles, categories, and so on.
I started to use the "str_slug" provided by Laravel which seems to do the job at 99%. The issue I get is when I have such title (in french): "J'ai mangé une pomme", the slug string I get is: "jai-mange-une-pomme" which, in french, is not correct. I would like "j-ai-mange-une-pomme".
It's not really an issue. I can do:
$slug = str_replace('\'','_',$input['name']);
$slug = str_slug($slug, '-');
It suits me well but I wonder how to use anytime I want to use it. I don't want to write it again and again and again.
In procedural, it's easy, I would write a function, such as thePerfectSlug(){} in a helpers.php file (still an example) and will use an include at the top of my index.php. That would do the job.
But in OOP and especially in Laravel (5.1), how can I do that?
Thanks
You still can achieve it with normal function. Laravel uses his own function which are stored in helpers.php file. You can make your own helpers.php file and add it to your main composer.json file at autoload.files.
If you would like to do it in OOP way, create a trait like App\Traits\Sluggify with your method and use it in any class that needs it.
I want to override the guestbook functionality. To be exact, I want to override the action_form_save_entry() function on [mysite]/concrete5/core/controllers/blocks/guestbook.php
I've tried to override it these ways:
[mysite]/controllers/blocks/guestbook.php
[mysite]/core/controllers/blocks/guestbook.php
noe of them works. I can't find any way how to override that file. The documentation here and here doesn't show how to override that /core/ directory. Their forum never helps. Google result also just get misled with the 'core' keyword. All the result just take the 'core' meaning as just what's exist on the /concrete5/ directory, not the exact true /concrete5/core
Looks like that /concrete5/core/ directory appear only on the newer version. CMIIW.
Btw, maybe I should also tell you what I want to do with that function. Probably you have another workaround for this instead of simply overriding it. I want to add SMS notification functionality to it. So whenever someone submit a new comment, an SMS would be sent to the admin of a particular page.
Yes, the /concrete/core directory structure is new to 5.6. Tutorials and documentation on c5 can be ... lacking ... but in this case it's just a matter of them being behind a bit.
The "real" guestbook controller is at /concrete/blocks/guestbook/controller.php. You'll notice that it's just a shell of a class:
class GuestbookBlockController extends Concrete5_Controller_Block_Guestbook {}
The file that you referenced defines Concrete5_Controller_Block_Guestbook.
So, the solution is to override the real controller, not whatever it extends (ie, the file that you were looking at). Thinking in this way, it should be clearer that you need to create a file at /blocks/guestbook/controller.php. In fact, just copy the controller.php that I referenced above because you need to keep the (sometimes multiple) classes. Then, you can override the particular function. (Don't forget to call parent::action_save_form_entry()).
I've used codeigniter in the past but on my current project I'm making the switch to Kohana. What is the best practice on constants?
In codeigniter there is the actual constants.php, but going through Kohana's source I'm not seeing something similar.
Never used kohana, but after a quick googling I find that you can use the config API to create your own config that will house the constants you need.
This thread suggests that if you are storing database sensitive items, to place them in the database.php config, etc.. making them relative to the type of data they are storing.
I'm familiar with Kohana, but not CI so much, so I'm guessing a bit to what you mean by 'constants.' I believe the closest thing to this is indeed Kohana's config API. So, if you wanted to make templates aware of some site-wide constant like your site name, that's a great thing to use the config API for.
To accomplish this, you'll need to create a config file under your /config folder, probably in the /application directory. What you call it isn't very important, but since it contains site information, let's call it site.php.
To quickly get going, here is what you'll want to have in that file:
<?php defined('SYSPATH') or die('No direct script access.');
return array(
// Your site name!
'name' => 'Oh me, Oh my',
);
Now, you can bring this in to a template by doing something like:
A better way to do this (using dumb templating) would be to assign this as a template variable in your Controller. So, assuming you have some default controller set up, the code would be:
public function action_index() {
$this->template->site_name = Kohana::config('site.name');
}
And then your template would have something like this:
<title><?php echo $site_name; ?></title>
Kohana's config API is interesting because it is hierarchical, meaning you can override and merge new configuration values on top of existing config structures. When you call Kohana::config('site.name'), the engine looks through all the config files named site.php, runs all of those config files and merges the results in to an array. The application-level config files will overwrite modules, which will overwrite system, etc... Then, based on that result array, Kohana will attempt to find the 'name' key and return it.
Assuming you want global constants...the following worked well for me.
application/config/constants.php:
define('MY_COOL_CONSTANT', 'foo');
return array();
index.php:
Kohana::$config->load('constants');
MY_COOL_CONSTANT should then be available globally.
Is the proper way to make a few variables available to all my controllers to add a MY_Controller.php file in my /application/libraries/ folder (shown in the docs here)?
I'm working in Kohana 2.3.4 and wondering if there are any better ways to do it, or is this the only recommended method?
Being new to OOP, can you link me to any examples?
I've heard the right answer is to add the vars to your $config[], trying to get more details.
The proper way is to make a custom config file (application/config/foobar.php), and access the data with Kohana::config('foobar.key').
The code igniter way is completely wrong and inappropriate.
See http://docs.kohanaphp.com/core/kohana#methods_config
How does this feel then:
[bootstrap.php]
Kohana::$config->attach(new Kohana_Config_File('global'));
And then, create a new file under application/config called global.php
In it, put (for example):
return (array ('MyFirstVar' => 'Is One',
'MySecondVar' => 'Is Two'));
Anywhere in your code, access these variables with
Kohana::config ('global.MyFirstVar');
As you can see, 'global.' is used to access these variables; the reason for that is that you attached the global.php config file at the beginning.
Was this what you meant? :-)
I'm building an MVC framework in PHP that will need to set a number of default configuration variables/constants. Example config vars would be where to save log files, whether to log queries, Doctrine settings, amongst many others. Because I want developers to be able to create new projects with minimal fuss, these config vars should have default values. However to make this framework truly useful, I need them to be able to override these default values either in a project bootstrap file, or from within a controller or model. I would love to use constants, but they cannot be overwritten. I feel as though there must be a simple solution that I just don't see (perhaps a design pattern?). Any advice would be greatly appreciated, thanks.
In a situation like this, I would probably :
Create a class that deal with everything configuration-related
That class would contain methods to get/set configurations options ; whatever your application needs
It would also define default values, when suitable
Use a .ini or .xml file, in which configuration values can be re-defined
When instanciating the class :
You already have the default values
You parse the .ini or .xml file
Each value defined in that configuration file is used to override the corresponding default value that what defined in the class.
A solution a bit more complex, but maybe better, might be to :
Still have that configuration class, but not use it to store any default values
Have one .ini or .xml file to store default values
Have one .ini or .xml file in which people can override the values defined in the default one
Load the file containing the default values, and then the one containing the specific ones
Advantages of this solution are :
No configuration value stored in a PHP class
All configuration options that can be overriden are already defined in a .ini / .xml file, which means people just have to copy/paste a line to their specific file to override : no need to go take a look at the PHP class and think "how do I translate this to a config file ?"
A couple more notes :
You might want to use some kind of caching-mecanism, to not re-parse the files at each request
Zend_Config and Zend_Config_Ini might be helpful ; even if you don't use those, as you are writing your own framework, you might want to take a look at what they do -- If I remember correctly, Zend_Config_Ini allows for hierarchy and inheritance in .ini files
Have fun!
I'd suggest using several ini files: a default.ini, and then as much override.ini-s as you need. Then simply load them with parse_ini_file() and merge into one config with array_merge(). Quick and simple.
Here's the design pattern I would use. I would create a simple class to facilitate it:
class Configuration {
String get($key) {...}
String set($key, $value) {...}
}
Initial implementation could all be hard-coded with default values. Later, though, you could slip in the reading of a server and/or project specific configuration file. It would give you flexibility to add as needed.
(I also noticed that the php.ini configurations seem to have the behavior you want, but I don't see how you leverage that system directly.)
This question can come with a wide variety of answers. My personal recomendation would be to store values into SQLite and have a seperate script to access and change those values. For other way continue to read.
This is pretty simple depending on how object oriented you want to be and how simplified you want to make things for your users. Your install instructions could simply instruct users to edit a file directly. In which case you could simply instruct users to edit a file of constants directly.
Most applications that follow this route implement it with detail explination
<?php
/**
* Global application configuration
*/
class AWConfig {
/**
* true or false
* If the is set to true debug messages will be added to the application logs
*/
public $DEBUG_MODE = true;
/**
* Path to Station database
* ex (/homepages/26/3/htdocs/databases/stations.db)
*/
public $DB_STATION = '/homepages/26/3/htdocs/databases/stations.db';
/**
* Path to logs database
* ex (/homepages/26/3/htdocs/databases/stations.db)
*/
public $DB_LOGS = '/homepages/26/d175338743/htdocs/weather/dev/metrics/beta2/databases/metriclogs.db';
/**** DO NOT EDIT BELOW THIS LINE *****/
public $LIST_STATION_LIMIT = 10;
public $MAX_COMPARE = 6;
}
?>
If you want to hide these details from the user than an initial setup script would be best that would prompt user for details and write a file (config.php, config.ini, config.xml, or to a database) the settings they chose. Then a different script to edit in the future. Good example would be Joomla CMS.