I need some help about the best way to persist an array of "settings" in php. The application load this settings every time that the page is "refreshed". I can't use databases and store the settings in a file is a bad idea if I need to check every time.
I think that a good solution is store the array (serialized) in a file and then read the file (only one time) and then "freeze" it in "a session"? But I don't know if its secure...
Can you help me?
EDIT:
i did forgot to say that the "settings" change more frecuently because the stored data, save a "cache table" of the rendered page modules. For this reason, i cant use a plain php file to store the settings.
There is no best way. You should choose from your needs. Each method has its own pros/cons. In case of database you will have network costs, but the opportunity to read settings from remote node or service may be beneficial. A file can be cached by php opcode cacher that will boost your app.
There is no need to "freeze" it in "a session".
Related
I'm working on an app using CakePHP, and I have some generic settings that admins can change that affect the whole site, but I'm not quite sure how to handle saving/editing the data. These settings are for site-control related things, such as enabling/disabling new user registrations, enabling/disabling creating of new posts/topics, etc...
Since these aren't specific to individual users and there is only 1 set of values for the entire site, is it more advantageous to just use an XML file or should I create a table (which would only have 1 row)?
If I go with the XML route, are there any security related issues I should be aware of?
I saw this post but the accepted answer was on a per-user basis. This is only 1 set for the entire site.
This sort of configuration is general best left inside a config file on disk.
Also, I wouldn't use XML. I would use JSON. It's much easier to deal with, and you get proper data types out of the box for normal things.
http://php.net/manual/en/function.json-encode.php
http://php.net/manual/en/function.json-decode.php
There are no special security issues to storing config on disk. Just keep it out of the web server's document root, like everything else that isn't intended to be loaded directly by the user. Your config and application code should be only writable by users with that privilege.
I think it should be added in database which make easier to make changes by administrators . It should be then cached and used for faster execution of settings. You can store cache in place you like and that is all you have to do.
Use http://book.cakephp.org/2.0/en/core-libraries/caching.html
I'm developing a generic app on PHP that is dynamically customized for many clients.
I have the class client, where I load the style and preferences for the client.
My question is:
Is it a good practice to save that object in a session? (I think that is the best solution instead of creating the object in each page, that will need lots of mysql querys.
There are few things you need to consider while you deal with session.
You should not store vary large values in session.
i think this is not a problem in your case as preferences are usally small enough.
When you store object in session. you might not get realtime updates. as for example lets say same user is logged in using two separate browsers and/or machines and modify preferences in one. in this case other one will not have the updated customization. its not a big problem but depends on your requirements.
I don't see any other problem here. in fact its valid and good solution to store small values in session and avoid db queries.
if it's something that won't change, and will just result in constantly calling MySQL queries over and over then yes, that is a good idea.
MySQL queries (and functions in general) are memory/cpu intensive and can affect page load speeds for the PHP, so the less work you are causing it to do the better.
if the returned values are going to be changing constantly it would be better not to, but store what values you can in the session.
I think the session will die when client close the browser.
If you store it in cookie (Loaded client) ? it not good for security.
When you store mini data in session (Loaded server).that mean you are using some memory at server.
What happen at the time you have many client ?
So, the database connection should be destroy at the end of process for each page.
Don't worry to use it.
I'm working on a big project with several http servers that use one main sql database.
The project has many settings that are frequently used(almost every request).
The settings are stored in the main sql database.
I wanted to know, if there is some way to initialize settings only once in php, because it makes no sense for every request to go and read same setting from sql server over and over again, it feels like a waste of resources.
Thanks in advance
2 solutions:
Create a (perhaps also PHP) script that exports settings from database into a plain text file, and includes that file on every http server;
use a memory cache server like http://memcached.org/ and preload data there from an external script, then have http servers connect to memcache instead of SQL.
Edit: Other than that, PHP does not give you a real web application, where you "run" your application and it has its own memory and persistant, global variables. This is one of the reasons I personally got tired of PHP and moved to Python (and Django, specifically).
Hard code these settings in your PHP code.
// Your current code, somthing like this:
$setting_1 = getDataFromMySQL('setting1');
// Hard coded
$setting_1 = TRUE;
You can use shared memory in php if it is compiled that way.
Another possibility is that you store a combined value of your settings as PHP code in one field (a PHP array for example), then you can read them all with only one query to the DB server. Of course this cached value have to be updated when settings change.
APC is the best solution if you are using a single server, otherwise I would go with memcached. However, you may also consider a MYSQL memory table, it is very efficient for fast reads and writes. Another solution is using Linux to keep and call settings with Linux exec. However, this might be a trouble and there might be some security issues. Also let me remind you that efficient INNODB indexes can help you a lot. MYISAM is also considered a good "read" performer, however my benchmarks show me that INNODB indexes are faster.
You can store the settings in the user's session -
session_start();
if (!isset($_SESSION['settings'])) {
$settings_array = //pulled from database
$_SESSION['settings'] = $settings_array;
}
That way, it'll only query once per user
You could use a session to store those settings.
I'm currently trying to create a CMS using PHP, purely in the interest of education. I want the administrators to be able to create content, which will be parsed and saved on the server storage in pure HTML form to avoid the overhead that executing PHP script would incur. Unfortunately, I could only think of a few ways of doing so:
Setting write permission on every directory where the CMS should want to write a file. This sounds like quite a bad idea.
Setting write permissions on a single cached directory. A PHP script could then include or fopen/fread/echo the content from a file in the cached directory at request-time. This could perhaps be carried out in a Mediawiki-esque fashion: something like index.php?page=xyz could read and echo content from cached/xyz.html at runtime. However, I'll need to ensure the sanity of $_GET['page'] to prevent nasty variations like index.php?page=http://www.bad-site.org/malicious-script.js.
I'm personally not too thrilled by the second idea, but the first one sounds very insecure. Could someone please suggest a good way of getting this done?
EDIT: I'm not in the favour of fetching data from the database. The only time I would want to fetch data from the database would be when the content is cached. Secondly, I do not have access to memcached or any PHP accelerator.
Since you're building a CMS, you'll have to accept that if the user wants to do evil things to visitors, they very likely can. That's true regardless of where you store your content.
If the public site is all static content, there's nothing wrong with letting the CMS write the files directly. However, you'll want to configure the web server to not execute anything in any directory writable by the CMS.
Even though you don't want to hit the database every time, you can set up a cache to minimize database reads. Zend_Cache works very nicely for this, and can be used quite effectively as a stand-alone component.
You should put your pages in a database and retrieve them using parameterized SQL queries.
I'd go with the second option but modify it so the files are retrieved using mod_rewrite rather than a custom php function.
I'm running a web application that allows a user to log in. The user can add/remove content to his/her 'library' which is displayed on a page called "library.php". Instead of querying the database for the contents of the users library everytime they load "library.php", I want to store it globally for PHP when the user logs in, so that the query is only run once. Is there a best practice for doing this? fx. storing their library in an array in a session?
Thanks for your time
If you store each user's library in a $_SESSION as an array, as you suggested (which is definitely possible) you will have to make sure that any updates the user makes to the library are instantly reflected to that session variable.
Honestly, unless there is some seriously heavy querying going on to fetch a library, or you have tons of traffic, I would just stick to 'execute query whenever the user hits library.php'.
Consider the size of the data. Multiply that by the maximum number of concurrent users.
Then compare that the to memory avaiable on your server. Also consider whether or not this is a shared server; other sites needs resources too.
Based on this, it is probably best to either create a file that can be used (as per Remi's comment), or remain in the default stateless form and read every time. I doubt that reading the data each time is creating much of an overhead.
When the user login you can generate a xml file (USER_ID.xml for instance) that you display with xslt.
http://php.net/manual/en/book.xslt.php
Each PHP script dies when it completes, so data can not be kept permanentely live in a web application as you would do in a PC application.
One way could be sessions, but it depends on the amount of data you want to save. According to your example you are talking about a library, so it sounds to me like big quantity of data need to be saved, in such case the DB is the way to go, and yes you have to query it each time.
Another way could be to save them in an array inside a php file, but in the same way you have to query the DB each time, you would have to include such php file each time.
Since this is a db performance optimization, I would suggest that you take a look at memcached which matches your problem perfectly:
memcached is [..] intended for use in speeding
up dynamic web applications by
alleviating database load.
I think it would be best to store it in a Session.
It the user logs in, the Session is being created and you can save data in it using the superglobal:
$_SESSION['key'] = "value";
You can also store Arrays or everything else there and it can be cleared if the user logs out.
you care for performance; Please note:
Session may use database or file to store data.
database is here to be used instead of files, for it's performance and abilities.
use database, it is designed to be used exactly in such situations!