I'm setting resources.frontController.throwExceptions = 1 (or true) in my application.ini but that doesn't seem to force the FrontController to throw exceptions.
I can see exceptions (output on the webpage) when I explicitly set protected $_throwExceptions = true; in Front.php in Zend library.
Any idea why the config setting doesn't work?
I am going to have a stab in the dark and guess that you're using APPLICATION_ENV to determine the section the INI to load.
To see the exception messages in the view (i.e. on the web page), you need to be displaying exceptions.
By default, only the development section has resources.frontController.params.displayExceptions = 1
So, if this is the case, APPLICATION_ENV must be set to development.
Related
I'm trying to setup my own Zend_Session_SaveHandler based on this code
http://blog.digitalstruct.com/2010/10/24/zend-framework-cache-backend-libmemcached-session-cache/
This works great, except that my session_id behave mysteriously.
I'm using the Zend_Session_SaveHandler_Cache class as you can find it in the blog above (except that I parked it in my own library, so it's name now starts with My_).
In my bootstrap I have:
protected function _initSession()
{
$session = $this->getPluginResource('session');
$session->init();
Zend_Session::getSaveHandler()->setCache( $this->_manager->getCache( 'memcached' ) );
}
To get my session going based on this code in my .ini file
resources.cachemanager.memcached.frontend.name = Core
resources.cachemanager.memcached.frontend.options.automatic_serialization = On
resources.cachemanager.memcached.backend.name = Libmemcached
resources.cachemanager.memcached.backend.options.servers.one.host = localhost
resources.cachemanager.memcached.backend.options.servers.one.port = 11213
So far so good. Until somebody tries to login and Zend_Session::rememberMe() is called. In the comments of Zend_Session one can read
normally "rememberMe()" represents a security context change, so
should use new session id
This of course is very true, and a new session id is generated. The users Zend_Auth data, after a successful log in, is written into this new session. I can see this because I added some logging functionality to the original class from the blog.
And here is where things go wrong. This new id isn't passed on the Zend_Session apparently, because Zend_Session keeps on reading the old id's session data. In other words, the one without the Zend_Auth instance. Hence, the user can no longer log in.
So the question is, how to make my saveHandler work with the new id after the regeneration?
Cheers for any help.
Ok, I'm blushing here....
I was looking at the wrong place to find this error. My session saveHandler was working just fine (so I can recommend Mike Willbanks his work if you want libmemcached session management).
What did go wrong then? Well, besides switching from file to libmemcached, I also switched from setting up my session in bootstrap to setting it up in my application.ini. So, instead of putting lines like
session.cookie_domain = mydomain.com
in my application.ini (which were then used in bootstrap as options to setup my session), I now, properly, wrote
resources.session.cookie_domain = mydomain.com
And this is were things went wrong, because.... I only changed those lines for production, I forgot to change them further down the ini file. In other words, my development env. got the cookie_domain of my production env., which is wrong as I use an other domain name during devolepment. So, on every page load, my cookie was invalidaded and a new session started. Mysterie solved...
I have searched and searched for this but I think my terminology isn't correct as it keeps giving me the application settings for the zend site rather than an application settings for the End User.
I'd like to have a config.ini type file that the end user can edit values in. I'd like it to be ONLY the settings I wish them to see and to be able to create the value names as I think would make sense to them. So it would be something like
[General]
SiteName=MySite
ShowResources=TRUE
[Database]
Server=myServer
databasepath=mydbpath
...
So my two questions.
1. What is this type of file called because when I search application settinsg, I get the ZF application settings not one for an end user (presumably)
What is the best way to handle this type of file?
Thanks
In your bootstrap add:
protected function _initConfig()
{
$config = new Zend_Config_Ini(APPLICATION_PATH.'/configs/config.ini');
Zend_Registry::set('config', $config);
return $config;
}
replace config.ini with whatever you want the filename to be.
You can then access this config object anywhere in your application either as an application resource or through the registry (Zend_Registry::get('config')). So to get the SiteName from your example:
$config = Zend_Registry::get('config');
echo $config->General->SiteName;
For things like database settings, you'll want to access these in the bootstrap so you can use them to setup other resources. I would recommend you don't try and include database settings in your application.ini as well, instead manually setup the DB resource by adding another bootstrap method:
protected function _initDb()
{
$this->bootstrap('config');
$config = $this->getResource('config');
$db = Zend_Db::factory('Pdo_Mysql', array(
'host' => $config->Database->Server,
'username' => $config->Database->Username,
'password' => $config->Database->Password,
'dbname' => $config->Database->Dbname
));
return $db;
}
To explain this some more, $this->bootstrap('config'); ensures the config resource is loaded first. $this->getResource('config'); returns the config resource (the one created by the _initConfig() method). It then uses the data from this object to create the DB connection.
It's an INI file, which you can read and write via Zend_Config.
ZF has no concept of "user settings" -- users are defined by you, not by the framework.
Apps usually store user configs in a database, but that's totally up to you. You could store a directory of INI files instead. Either way, you have to do the implementation yourself.
Edit: Given that you have a ZF app that you're distributing to the customer, and they're only ever going to connect to one database with it, that changes things significantly. (I thought you originally meant that you'd have one instance of the app simultaneously connecting to multiple databases.)
In your case, I would use the standard ZF application/configs/application.ini file for your application's "internal" settings. Then, I'd have a separate local.ini (or whatever) in that same application/configs directory, which contains only those settings that you want the customer editing. Distribute a skeleton local.ini file with the app, that has instructions right in it, something like this:
; Remove the comment from this line.
;configured = 1
; You need to put your database credentials in here.
db_host = "PUT YOUR DATABASE SERVER NAME HERE"
db_user = "PUT YOUR DATABASE USERNAME HERE"
db_pass = "PUT YOUR DATABASE PASSWORD HERE"
Then just load the local.ini file via Zend_Config. I'd also add a check to your index controller's init method that checks to see if you're properly configured:
$localConfig = Zend_Registry::get('local_config'); // or wherever you put it
if (!$localConfig->configured) {
$this->_helper->redirector('config', 'error');
}
And then make a error/config view that says:
You didn't read the instructions. Go do that now.
Note there's nothing stopping the customer from editing anything they want, but this makes a logical separation and makes it harder to accidentally screw something up.
I'm writing to see if someone of you guys has encountered this problem before and have a chance to understand why it happened to me.
This is the story.
I developed many ZF applications before Zend Framework v. 1.8, then I've stopped for about 18 months. Now I had to start a new project on which I decided to use Zend Framework again.
On my local server I had the version 1.11.3 installed, so I didn't download the latest release.
Before the use of Zend_Application with the Bootstrap.php file I used to start sessions putting my session options in my config.ini file and then loading them into a Zend_Session instance like this:
config.ini
sessions.name = NAME
sessions.use_only_cookies = 1
sessions.save_path = APPLICATION_PATH "/../tmp/sessions"
sessions.strict = on
sessions.remember_me_seconds = 1800
index.php (into the public webserver directory) before starting the application:
Globals::startSession();
custom Globals class with various useful methods:
class Globals
{
static public function startSession()
{
$sessions_conf = self::getConfig()->sessions;
Zend_Session::setOptions($sessions_conf->toArray(););
Zend_Session::start();
}
}
This has always worked very well, enabling my sessions (used with Zend_Session_Namespace) and storing the session files in the save_path.
With Zend_Application the manual tells to simply store the session options in the application.ini file under the "section" resources and Zend_Session will be configured automatically...
I did it like this:
; SESSIONS
resources.session.name = NAME
resources.session.use_only_cookies = 1
resources.session.save_path = APPLICATION_PATH "/../tmp/sessions"
resources.session.strict = on
resources.session.remember_me_seconds = 1800
It didn't worked.
So I tried to use (not at the same time!) the _initSession() and _initForceSession() methods in the Bootstrap.php file, putting them at the beginning of the class and writing into them the code:
$this->bootstrap('session');
But session were never working, data were not stored between http requests and session files were never written into the save_path...
Could anyone, please, let me know if this is a normal behaviour (maybe I have missed something somewhere...)?
Obviously I solved the problem re-implementing my older method (and it works perfectly), but I would like to learn how to use it correctly.
Thanks in advance.
This should be a case of turn it on and it works, might have made it to easy.
I think you may have a problem with how you set your options in your application.ini:
; SESSIONS
resources.session.name = NAME
resources.session.name.use_only_cookies = 1
resources.session.name.save_path = APPLICATION_PATH "/../tmp/sessions"
resources.session.name.strict = on
resources.session.name.remember_me_seconds = 1800
according to the reference manual
To set a session configuration option, include the basename (the part
of the name after "session.") as a key of an array passed to
Zend_Session::setOptions().
with your options set correctly the bootstrap _initSession() should just work.
public function _initSession()
{
Zend_Session::start();
}
P.S. I use Zend_Session_Namespace all the time but rarely deal with a global session.
In your Bootstrap.php add
public function _initSession()
{
Zend_Session::start();
}
session options can be set in application.ini
You have to promise not to giggle, but my situation is following:
Instead of using partials and helpers and other similar tools that we use already, we want to use a custom view outside all frames and borders of the actual application. Basically, we need at this point to load clean HTML into a variable upon a certain reaction a model. That is monkeys business and can be done by virtually anyone without using a keyboard.
The problem is that the HTML pages that we want to create are supposed to be quite extensive and are a trainwreck to debug/maintain/expand due to the inate "return $arrlglllgll;" approach. To make a smooth and humane script, we would very much love to use the .phtml style with clean html mixed up with php injections without actually rendering it.
Is that possible and how?
I am currently struggling with
$mailView = new Zend_View();
$mailView->setScriptPath('/Templates');
echo($mailView->render('test.php'));
die;
Where test.php is a file I have been trying to reach with any means and corelations imaginable, but ultimately failed every time due to
exception 'Zend_View_Exception' with message 'script 'test.php' not found in path (\library\Extras\Controller\Action\Helpers\)' in \library\Zend\View\Abstract.php:875
Stack trace: blablabla
Loading a custom view from a controller is butt-easy, just provide the relative path and you're set, but it seems that I cannot find anything if I shoot from within a library. Any advice?
In case anybody wonders, this is a lot easier than I ever thought it to be...
// Set the view
$layout = new Zend_Layout();
$view = $layout->getView();
// Send inherited custom parameters
$view->params = $params;
You can thus use the $view as a real view and load any $view->helper as you please.
To save rendered view, type...
$savingParameter = $view->render('controller/subfolder/' . $page . '.phtml');
TADAA
I'm trying to copy a site built on ZF from production to a localhost environment. All files and db contents were copied but I just get a blank screen. No errors, nothing
Changes made in config.ini I added an entry for development:production
general.host = "localhost:8888"
db.adapter = PDO_MYSQL
db.params.host = localhost:8888
db.params.username = bla
db.params.password = bla
db.params.dbname = db_name
bootstrap.php
$frontController->registerPlugin(new Initializer('development'));
.htaccess contains a few basic directives but if I put some random stuff at the top I don't get Internal server errors so I don't think it even reaches the .htaccess stage.
Did I miss some kind of configuration somewhere?
EDIT:
I have code below in my bootstrap but still get a blank page. Very quickly, it barely loads at all
$frontController->registerPlugin(new Initializer('development'));
$frontController->throwExceptions(true);
// Dispatch the request using the front controller.
try {
$frontController->dispatch();
}
catch (Exception $exception)
{
exit($exception->getMessage());
}
Try adding this line before running dispatch() on front controller object.
$frontController->throwExceptions(true);
On production systems throwing exceptions is almost always disabled, enabling it on dev could tell you more about the nature of the problem.
Yes, you probably missed some configuration.
Try setting display_errors=On in php.ini. You should be able to see what is going on.
Also, like suggested - try putting $frontController->throwExceptions(true) before calling dispatch().
Regarding the .htaccess file - you need to put the AllowOverride All (or anything valid, other than None) in your apache.conf/vhosts config.