Mysql users are stored into ‘mysql’ db and ‘user’ table, therefore to retrieve the list of all registered users, simply execute the following query:
select * from mysql.user;
or, for a less detailed list:
select User, Host, Password from mysql.user;
Mysql users are stored into ‘mysql’ db and ‘user’ table, therefore to retrieve the list of all registered users, simply execute the following query:
select * from mysql.user;
or, for a less detailed list:
select User, Host, Password from mysql.user;
Due to badly implemented shell script I had to give root user’s password to a shell script (pretty ugly I must admit!).
Problem is that with ubuntu, by default you cannot use root user account. To change this simply run: “sudo passwd root” and then set your password for root user.
If you want to go one step further and login into gnome as root (which I recommend NOT to do at all – I personally do not do it, never), then do the following:
That’s it.
This tip is useful when you have several projects on the same server.
To set a php ‘include_path’ customized to each project, in your <VirtualHost *:80> (or equivalent) definition, simply add:
php_value include_path ".:/path/to/site:/another/path"
save your changes, check your config (sudo apache2ctl configtest) and restart apache (sudo /etc/init.d/apache2 restart).
That’s it.
(apply to ZF v1.10)
You have two types of resources:
- class resources (those methods that you define in your Bootstrap class and that starts with ‘_init’)
- plugin resources (those that you define externally and can trigger via application.ini file)
How do you automatically load an external resource from application.ini file?
This is pretty simple indeed. You only have to declare your resource in your config file as follow: “resource.<resource_name> = true”
note: we added ” = true” because otherwise our line would have been ignored since no value was defined to our <resource_name> variable. In next section, we will add some parameters therefore making explicit use of ” = true” useless.
How do you provide options to your own external plugin resource?
Anything that will come after ‘resources.<resource_name>’ in your application.ini file will be considered an option and provided to your external resource upon instanciation.
If I write
resources.myplugin.option1 = 1
resources.myplugin.option2 = 2
Then ‘myplugin’ is automatically registered and will be instanciated with following options array ['option1' => 1, 'option2' => 2, 'bootstrap' => Object]
note: ‘bootstrap’ entry is automatically created by ZF (Zend_Application_Bootstrap_BootstrapAbstract) and therefore available to all plugins. It contains an instance of the bootstrap object.
Example:
in my application.ini, I have:
resources.db.adapter = “PDO_MYSQL”
resources.db.params.host = “localhost”
resources.db.params.username = “user”
resources.db.params.password = “pwd”
resources.db.params.dbname = “mydb”
Then what’s going to happen is:
[ 'adapter' => 'PDO_MYSQL', 'params' => [ 'host' => 'localhost', 'username' => 'user', 'password' => 'pwd', 'dbname' => 'mydb'], 'bootstrap' => Object ]
note: for bootstrap entry, see above comment
How do you use Router resource?
ZF online documentation still contains example for old routing (ie. as it was performed prior to introduction of Zend_Application and external resources). Now it’s better to call external resource plugin rather than configure your Zend_Controller_Front as done previously.
To do this, it’s pretty simple. You can rely on examples provided in online documentation (http://framework.zend.com/manual/en/zend.controller.router.html), the only change that you have to do is to prefix all ‘routes’ entry in your application.ini file with ‘resources.router.’.
Thus,
routes.login.type = “Zend_Controller_Router_Route_Static”
routes.login.route = “login”
routes.login.defaults.controller = auth
routes.login.defaults.action = login
becomes
resources.router.routes.login.type = “Zend_Controller_Router_Route_Static”
resources.router.routes.login.route = “login”
resources.router.routes.login.defaults.controller = auth
resources.router.routes.login.defaults.action = login
That’s it. You don’t have to worry about anything else, a router instance is automatically created and your routes should be active now.
How do you use Log resource via .ini configuration?
In my case, I defined it this way:
resources.log.stream.writerName = “Stream”
resources.log.stream.writerParams.stream = APPLICATION_PATH “/../logs/app.log”
resources.log.stream.filterName = “Priority”
resources.log.stream.filterParams.priority = Zend_Log::WARN
Where can you access all instances used by external resource plugins?
Db plugin instanciates a Zend_Db_Adapter object, Log plugin instanciates a Zend_Log object, and so on…
Everytime a ->init() method of a resource plugin returns a value, this value is store in a container currently being a Zend_Registry instance (but not singleton).
As a consequence, once Db resource has been bootstrapped, you can access create db adapter instance in $bootstrap->getResource(‘db’); (and $boostrap->getResource(‘log’) for Log instance!)
How do you write your own external plugins?
pluginPaths.My_Plugin_Prefix = APPLICATION_PATH "/path/to/my/resource/plugin/directory"
resources.myResource = true
note: you can add parameters to this call (as explained above) that will be available in your resource plugin class via ->getOptions() method
Almost all browser makes a query for /favicon.ico file.
When you use ZF, all your queries that do not match an existing physical file are rerouted to your bootstrap file and therefore go through your entire app to end-up in a 404 error.
Well this is a waste of computing resources and above all can drives you crazy when you’re tracking errors. You might not understand why your query runs twice on a single page load…
A quick and easy way to fix this is simply to create an empty file, name it ‘favicon.ico’ and place it in your /public folder.
If you want to skip the request call via .htaccess instead, simply preprend the following line to your rewrite condition:
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/favicon.ico$ [OR]
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
That’s it.
Good luck.
When you define an .ini file, you can divide your content in sections so that you can load on some sections or you can even implement section inheritance so that you have customized values based on your given configuration.
Lets’ see a quick example:
$ini = <<<EOF
[base]
host=localhost
user=testuser
pass=testpass
database=default
[users:base]
database=users
[archive : base]
database=archive
EOF;
$opts = parse_ini_string($ini, true);
var_dump($opts);
//output
array(3) {
["base"]=>
array(4) {
["host"]=>
string(9) "localhost"
["user"]=>
string(8) "testuser"
["pass"]=>
string(8) "testpass"
["database"]=>
string(7) "default"
}
["users : base"]=>
array(1) {
["database"]=>
string(5) "users"
}
["archive : base"]=>
array(1) {
["database"]=>
string(7) "archive"
}
}
Inheritance mechanism is implemented in Zend Framework through Zend_Config_Ini class.
Splitting a section in multiple parts
Unfortunately splitting a section in multiple parts might not work as expected. Your entire section is overwritten and no simply merged.
Let’s have a quick look:
$ini = <<<EOF
[base]
host=localhost
user=testuser
pass=testpass
database=default
[users : base]
database=users
[archive : base]
database=archive
[base]
koko=kiki
EOF;
$opts = parse_ini_string($ini, true);
var_dump($opts);
//output
array(3) {
["base"]=>
array(1) {
["koko"]=>
string(4) "kiki"
}
["users : base"]=>
array(1) {
["database"]=>
string(5) "users"
}
["archive : base"]=>
array(1) {
["database"]=>
string(7) "archive"
}
}
too bad…
Nothing easier!
That’s it.
Nothing easier.
We just bought a brand new computer with windows 7 on it, and once at home, we tried to change the language because although living in the country where we bought it, our native language is not the one that was on the computer.
Guess what, if you want to change the language that your windows speaks, well you have to spend 190 euros!!!!
You cannot do it without having windows ultimate, and when you buy a new computer you don’t have any choice and just have windows premium or equivalent. Now you have to upgrade just to change OS language, simply because some crazy people at Microsoft tried to earn quick and cheap money stating that changing your OS language is equivalent to being a new user so that you have to buy another windows licence!!!
Simply pure non-sense and commercial-driven thinking.
All the more when you consider that windows 7 is merely a service pack of vista and you should not have to pay for it.
Well anyway, by chance, there are some skilled people in town that tries to make this world fairer. And thanks to them you don’t have to pay microsoft their crazily overpriced language-fee, use tools and instructions described on this website: http://www.froggie.sk
It worked for me pretty well.
High 5 to froggie!
ps: due to a windows bug (well done crofties…), I had to move downloaded MUI file to another location (desktop) prior to loading it through Vistalizator
When I tried to run “sudo dpkg-reconfigure locales” to add a new locale as I used to do it on debian, it simply regenerated my existing locales without letting me the choice to add/remove new ones!
After searching the web, it looks like under ubuntu you need to:
I’m pretty sure (at least I hope) there’s a better way to do it, but this way worked for me.
If you want to list all cron jobs, let’s say to track down a process running widly on its own every day
, don’t forget to check the following:
ls -l /var/spool/cron/crontabs
then examine all user files