My application need to use database instead of file for the session management.
My Application is based on Zend Framework 1.12.17, php 5.6.25 and actualy on wampserver
That is my config.ini
resources.session.use_only_cookies = true
resources.session.gc_maxlifetime = 864000
resources.session.remember_me_seconds = 864000
resources.session.gc_probability = 1
resources.session.gc_divisor = 100
resources.session.saveHandler.class = "Zend_Session_SaveHandler_DbTable"
resources.session.saveHandler.options.name = "app_session"
resources.session.saveHandler.options.primary = "id"
resources.session.saveHandler.options.modifiedColumn = "modified"
resources.session.saveHandler.options.dataColumn = "data"
resources.session.saveHandler.options.lifetimeColumn = "lifetime"
When I want to upgrade php to php 7.0.10, a warning occurred
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (D:\wamp\www\myapp\top\session) in D:\wamp\www\myapp\top\library\versions\ZendFramework-1.12.17-minimal\library\Zend\Session.php on line 732
I'm looking for the origin of this problem. Do you have an idea?
Thanks a lot
On September 2016, Zend Framework 1 is reached EOL (end-of-life). This means it will not be improved anymore. The codebase is too old to work well with PHP 7.
Anyway, you have at least two option:
Downgrade to or run in parallel PHP 5.6 on your server to support ancient ZF1 app.
Write your own session save handler by extending the DbTable handler as suggested here.
The issue is written here: https://github.com/zendframework/zf1/issues/665#issue-127528467
Since an update that returns 0 but doesn't throw an exception was still a successful query with no error
Hence the function write will return false instead of true, and PHP 7.0 requires a true result.
You can fix this by changing, in Zend/Session/SaveHandler/DbTable.php:
if ($this->update($data, $this->_getPrimary($id, self::PRIMARY_TYPE_WHERECLAUSE))) {
To:
if (is_int($this->update($data, $this->_getPrimary($id, self::PRIMARY_TYPE_WHERECLAUSE)))) {
Or you can also remove the if, turn it into an instruction, and keep the $return = true;. Because on error, the query should raise an Exception, so any update() without Exception is good.
In addition to edigus answer here is such a simple implementation of the extended save handler:
<?php
require_once 'Zend/Session/SaveHandler/DbTable.php';
// NOTE: To fix an issue with Zend_Session_SaveHandler_DbTable on PHP 7 this class extends it and overrides the write
// method to simply always return true.
//
// See: https://stackoverflow.com/a/44985594/1510754
// See: https://github.com/zendframework/zf1/issues/665
// See: https://github.com/zendframework/zf1/pull/654
class My_Session_SaveHandler_DbTable extends Zend_Session_SaveHandler_DbTable
{
public function write($id, $data)
{
parent::write($id, $data);
return true;
}
}
Related
My source Yii have this problem , when i use xdebug. I don't know why.
It looks like you use Yii 1 with PHP 7.2
According to this post and number of other sources like this one and this one, you have a yii bug that can be reported here
The answer from the other topic:
I have done a bug report at php.net and they explained that this is
not a bug. Yes in PHP 7.2 a warning is generated now. However this
never worked as intended, it just failed silently.
For creating multiple sessions it is required to use session_id().
Have a look at this related question: PHP How can I create multiple
sessions?
session_name() as well as session_set_cookie_params() are always
nonesense if the session is already running.
For the original answer have a look here:
https://bugs.php.net/bug.php?id=75650&thanks=2
Simple fix:
function _read($id)
PHP 7.0 -> if is empty return false
PHP 7.2 -> if is empty return ''
then add # to other functions and remember to run session_name before session start
#session_name('SOMEID');
#session_start(...
...
#session_set_save_handler(...
It's work for me:
Make new class SomeSession in protected/components folder:
class SomeSession extends CCacheHttpSession
{
public function open()
{
// don't start new session if session is started now
if (session_status() === PHP_SESSION_NONE)
{
parent::open();
}
}
in main.php in session section edit:
'session' => [
'class' => SomeSession::class,
'sessionName' => 'SomeSessionName',
'autoStart' => true,
'cookieMode' => 'allow',
]
done =]
I'm using The Symfony Lock package to check if a class method can be executed
if ($this->lock->acquire()) {
$this->execute();
$this->lock->release();
}
Important: I'm not using the Symfony Framework, only the Lock component
I want to make a test that asserts that the execution is locked when running in multiple threads, but I have not found any documentation on how to achieve this.
Is it a good idea to use pthreads? If not, which is the best way to make this test?
Thank you very much.
Referring to the Lock Component documentation :
https://symfony.com/doc/current/components/lock.html#usage
Information on the CommandTester :
https://symfony.com/doc/current/console.html#testing-commands
Solution for PHPUnit test :
use Symfony\Component\Lock\Factory;
use Symfony\Component\Lock\Store\SemaphoreStore;
public function testLockIsSet()
{
// Create a new Semaphore lock with the same ID as the one that would be
// created if you were running the command / class / process etc.
$store = new SemaphoreStore();
$factory = new Factory($store);
$lock = $factory->createLock('lock-name-used-eg-generate-pdf');
if ($lock->acquire()) {
// In my use case I was running multiple commands to see if the lock
// was working properly
$commandTester = new CommandTester($this->command);
// Try and run the command. The lock should already be set.
$commandTester->execute(
[
'command' => $this->command->getName()
]
);
// You could also use expectException() here for LogicException
$this->assertContains(
'The command is already running in locked mode.',
$commandTester->getDisplay()
);
$lock->release();
}
}
I'm writing controller testing unit with Fuelphp framework. And inside the code I'm trying to request application controller like this one :
$response = Request::force('controller_name/controller_method')->set_method('GET')->execute();
But this code unexpectedly exits the entire testing unit like PHP exit function. After trying to figure out what happened inside the core source code, I found out that in line 440 of https://github.com/fuel/core/blob/1.9/develop/classes/request.php forces the program to exit without any exception.
$this->controller_instance = $class->newInstance($this);
And before this code
$class = new \ReflectionClass($this->controller)
I'm using PHP 5.6.33 and Fuelphp 1.7.2 in my machine and I hope someone can help me with this error.
I think it's just a typo in your question but to be sure : you said
Request::force
instead of
Request::forge
Anyway, I have a lot of tests wrote in the same way but we add few lines before calling forge it :
$_SERVER['REMOTE_ADDR'] = '127.0.0.1';
$_SERVER['HTTP_ACCEPT'] = 'application/json'; // this one may not be required for you
$_POST = array();
$_GET = array();
$request = \Request::forge('controller/action')->set_method('GET');
$request->execute();
I'm using configureMonologUsing() to add in two custom loggers. Doing the standard SOLID principal, I have two providers: ConsoleLoggerProvider and MailLogProvider.
Both of these have a register similar to:
public function register()
{
app()->configureMonologUsing(function(\Monolog\Logger $monolog) {
$monolog->pushHandler(new HandlerClass());
});
}
However, I have noticed over logger will overwrite another logger... How do I stack these?
I've tried to use boot() as well, and that didn't work. I couldn't find any other way to add to the Monolog stack.
Preferable, I want to stack onto Laravel's built-in logger as well.
I (finally) found the answer my question:
Within my providers, instead of using configureMonologUsing(), I used Log::getMonolog()->pushHandler([..])
That works! All loggers, including built-in Laravel file logger, are firing. Finally!
(I've honestly been looking for days for a way to add onto the Monolog stack; I apparently wasn't searching by the right terms)
According to the Laravel documentation:
You should place a call to the configureMonologUsing method in your bootstrap/app.php file right before the $app variable is returned by the file.
In that case, thus should work for you: create two handler classes and add them to monolog this way (in your bootstrap/app.php):
$app->configureMonologUsing(function ($monolog) {
$monolog->pushHandler(new EmailLogHandler);
$monolog->pushHandler(new ConsoleLogHandler);
});
return $app;
Following Laravel 5.2 docs, in bootstrap/app.php, I added the following code right before return $app;:
$app->configureMonologUsing(function($monolog) {//IMPORTANT: I think the order of pushHandler matters, and the ones defined last here will be the first to be called, which affects anything where bubble=false
if (config('services.slack.send_errors_to_slack')) {
$bubble = false; //I think that if I set the 'bubble' argument to false and handle the most severe logging levels first (which counterintuitively means lower in this function), less severe logging levels don't bother reporting the same message.
$useShortAttachment = false;
$includeContextAndExtra = true; //This is important because otherwise 404 errors wouldn't report the URL, give how 'report' function is coded within App\Exceptions\Handler.php.
$handlerForWarningsToNotifyPhone = new \Monolog\Handler\SlackHandler(config('services.slack.token'), config('services.slack.channel_warnings'), 'Monolog', true, null, \Monolog\Logger::WARNING, $bubble, $useShortAttachment, $includeContextAndExtra);
$monolog->pushHandler($handlerForWarningsToNotifyPhone);
$handlerForErrorsToNotifyPhone = new \Monolog\Handler\SlackHandler(config('services.slack.token'), config('services.slack.channel_errors'), 'Monolog', true, null, \Monolog\Logger::ERROR, $bubble, $useShortAttachment, $includeContextAndExtra);
$monolog->pushHandler($handlerForErrorsToNotifyPhone);
}
if (config('app.send_logs_to_loggy')) {
$logglyHandler = new \Monolog\Handler\LogglyHandler(config('services.loggly.token'), config('app.send_logs_to_loggy')); //See \Monolog\Logger::INFO. Log level 200 is "info".
$logglyHandler->setTag(config('services.loggly.tag'));
$monolog->pushHandler($logglyHandler);
}
if (config('app.log_to_local_disk')) {
$localHandler = new \Monolog\Handler\StreamHandler(storage_path("/logs/laravel.log"));
$monolog->pushHandler($localHandler);
}
});
It's just an example that may help you.
Be sure to edit your config files accordingly (e.g. so that app.log_to_local_disk, services.slack.send_errors_to_slack, etc are available).
http://stackoverflow.com/a/36259944/470749 was helpful.
Here is how I able to configure on Laravel Lumen v5.4
in app.php:
$publisher = new \Gelf\Publisher(new \Gelf\Transport\HttpTransport(env('GRAYLOG_HOST'), env('GRAYLOG_PORT'), env('GRAYLOG_PATH')));
//WhatFailureGroupHandler does not break app execution
//if some exceptions happen happens while logging
$failureHandler = new \Monolog\Handler\WhatFailureGroupHandler([
new \Monolog\Handler\GelfHandler($publisher)
]);
\Log::pushHandler($failureHandler);
\Log::getMonolog() as on accepted answer threw error.
Also tried to configure using $app->configureMonologUsing() which threw A facade root has not been set. error. But at the end, I found out that was because we need to return logger:
$app->configureMonologUsing(function ($monolog) {
$publisher = new \Gelf\Publisher(new \Gelf\Transport\HttpTransport(env('GRAYLOG_HOST'), env('GRAYLOG_PORT'), env('GRAYLOG_PATH')));
$failureHandler = new \Monolog\Handler\WhatFailureGroupHandler([new \Monolog\Handler\GelfHandler($publisher)]);
$monolog->pushHandler($failureHandler);
//fixes error: A facade root has not been set
return $monolog;
});
All the examples of $app->configureMonologUsing() usage I have seen do not have a return statement, even in the other answers, which did not work for me.
I'm having troubles with PHP MongoCursor since I upgraded to Mongo PHP Driver from 1.5.8 to 1.6.0
The following code works well with version 1.5.8, but crashes with version 1.6
PHP version is 5.5.21., Apache version is Apache/2.4.10 (Ubuntu)
$mongoClient = new \MongoClient($serverUrl, ['readPreference'=>\MongoClient::RP_NEAREST]);
$database = $mongoClient->selectDB($dbName);
$collection = $database->selectCollection($collectionName);
// count() works fine and returns the right nb on documents
echo '<br/>count returned '.$collection->count();
// find() exectues with no error...
$cursor = $collection->find();
$documents = [];
// ...and hasNext() crashes with the Excetion below
while($cursor->hasNext()){$documents[] = $cursor->getNext();}
return $documents;
And so the hasNext() call crashes with this message :
CRITICAL: MongoException: The MongoCursor object has not been correctly initialized by its constructor (uncaught exception)...
Am I doing something wrong ?
Thanks for you help !
This may be related to a bug that was introduced in 1.6.0 regarding iteration with hasNext() and getNext(): PHP-1382. A fix has since been merged to the v1.6 branch and should be released later this week as 1.6.1.
That said, the bug regarding hasNext() was actually that the last document in the result set would be missed while iterating. If I run your original script against 1.6.0, the array contains a null value as its last element. With the fix in place, the array will contain all documents as is expected. I cannot reproduce the exception you're seeing with either version.
That exception is actually thrown from an internal checks on the C data structures, to ensure that the cursor object is properly associated with a MongoClient and socket connection. See the MONGO_CHECK_INITIALIZED() macro calls in this file. Most all of the cursor methods check that a MongoClient is associated, but hasNext() is unique in that it also checks for the socket object (I believe other methods just assume a cursor with a MongoClient also has a socket). If that exception is truly reproducible for you and you're willing to do some debugging with the extension, I'd be very interested to know which of the two checks is throwing the error.
As a side note, you should also be specifying the "replicaSet" option when constructing MongoClient. This should have the replica set name, which ensures that the driver can properly ignore connections to hosts that are not a member of the intended replica set.
I just encountered the same issue; I refactored my code to use the cursor iterator instead, ie:
foreach( $cursor as $doc ) {
$documents[] = $doc;
}
I was looking for a code example of how to implement a tailable cursor and found this question. The following code is a simple example of a tailable cursor (via the $cursor variable) which you provide on a capped mongodb collection.
$cursor->tailable(true);
$cursor->awaitData(true);
while (true) {
if ($cursor->hasNext()) {
var_dump($cursor->getNext());
} else {
if ($cursor->dead()) {
break;
}
}
}