Anyone out there working with Phalcon on CentOS?
I'm trying to use Syslog from Phalcon\Logger\Adapter\Syslog but can't find where can I see the output. AFAIK, CentOS send syslog messages to '/var/log/messages', but I've looked at almost all files in '/var/log' and found nothing.
Currently I'm constructring the Syslog this way:
$logger = new SyslogAdapter(null);
Is there any setting that I'm missing on Phalcon or my OS?
Looking at https://github.com/phalcon/cphalcon/blob/master/ext/logger/adapter/syslog.c#L125 and https://github.com/phalcon/cphalcon/blob/master/ext/logger/adapter/syslog.c#L185 it seems that Phalcon proxies all calls to the default syslog.
I'd sugget to goggle "centos php syslog" and make it work in pure php without Phalcon. It feels this is the keystone to the problem.
Update
Just looking over your piece of code, the actual class is called Syslog, not SyslogAdapter, unless you do use Phalcon\Logger\Adapter\Syslog as SyslogAdapter;, which I can't tell from the code above :) If syslog via php works, then most likely the issue is with your code. I just tried the below, it works as expected:
$logger = new Syslog(null);
$logger->log('test', 'hello world');
// 27/04/2014 19:15:24.922 php[24030]: hello world
Related
is it possible to to use Datahander Scripts (TCEmain) in a Extbase Command Controller via cli_dispatch.phpsh? I tried but i got no result - no error message and no entry in the tables.
Perhaps there is no backend available in cli scripts ...
Thanks!
You find the documentation for using DataHandler in CLI scripts here.
CLI scripts use the backend user _cli_ (should be created automatically). You can take a look at the source of \TYPO3\CMS\Backend\Console\CliRequestHandler::boot if you're interested in how it works.
You can check the public instance variable $dataHandler->errorLog for any errors, DataHandler won't output anything else.
Mind that cli_dispatch.phpsh & Co. are deprecated, you can already use Symfony Commands in TYPO3 CMS 8.
I have a ZF3 project with a controller which opens excel-files and compares them with an template which will be openened, too.
On my development notebook (xampp) everything works fine, at my production system (ubuntu) the phpspreadsheet causes errors (I think it is the one).
here a snippet from my code:
$fileName="./public/files/" . $fileName; //.\ neu
echo $fileName;
$template= new Spreadsheet();
$importdcl= new Spreadsheet();
$template= \PhpOffice\PhpSpreadsheet\IOFactory::load('./public/files/Template_DCL_final.xlsx');
$importdcl= \PhpOffice\PhpSpreadsheet\IOFactory::load( $fileName);
echo "filename geladen";
I already have the folders in non relative paths because basePath() doesn't work, it won't give any result.
The echo statement is just because the server log won't give any errors. On my development system I get the echo text on my production system the error seems to be at the load statements.
First question: How could I use relative paths in here?
Second question: How can I get an idea wether is something wrong with the spreadsheet class?
This is what composer loaded:
"phpoffice/phpspreadsheet" : "dev-develop",
Is it a problem, because it has this dev version? At this point I'm quite confused because I played with the pathes of the files, I changed the rights manually in the folder, I checked server logs and now I don't have any idea left.
Here the rights in the folder:
Any helpful suggestions appreciated.
Answer (hopefully) to the first question: if your application is based on ZendSkeletonApplication, then you can use paths relative to your application root (from index.php):
/**
* This makes our life easier when dealing with paths. Everything is relative
* to the application root now.
*/
chdir(dirname(__DIR__));
So if your data files are located in <application root>/public/files, then you should be able to read them from controller/service/etc. using public/files/<file name> path. You can test it with eg. the file_exists function.
I’m unable to answer your second question, but here are some suggestions (OK, questions…):
what is the status code of your (production) server’s response?
Do you have read/write permissions to the data files from the server’s account (www-data?)?
Does phpspreadsheet depend on any PHP extensions? Do you have them installed on both your development machine and the server?
What PHP version is installed on the server? Do you or phpspreadsheet use any features that may be unavailable on that version?
Try running your project not through Apache, but with PHP’s builtin server (but don’t do it long-term) and try to reproduce the issue.
Can I use memcachier with ZendFramework 1.12 ?
The provider that I am useing(AppFog) only offers Memcachier (Memcached is comming soon from 10 Months) And My app will need a lot of caching when it starts. I don't want to stick with APC so I have no other good alternative.
So this is just a half answer right now, I'll try to figure out the rest. I work for MemCachier by the way, so please shoot us an email on support#memcachier.com if you have more questions.
PHP includes two memcache bindings by default: memcache and memcached. The first one (memcache) is its own implementation of the memcache procotol, while the second one (memcached) is a php binding to the libmemcached C++ library.
The memcached binding for php does support SASL these days (since version 2.0.0). Sadly it isn't documented. It also is an optional part of the memcached module, so you'll need to make sure it is compiled on your machine (or AppFog) with the SASL support enabled. The steps to do that roughly are:
Install libmemcached. I used version 1.0.14.
Install php-memcached. Make sure to pass the "--enable-memcached-sasl" option to it when running ./configure.
When building both of these you can sanity check the output of "./configure" to make sure that SASL support is indeed enabled, sadly right now it can be tricky.
Edit you php.ini file. Put the following line into it:
[memcached]
memcached.use_sasl = 1
I did all of this on OSX 10.8 using homebrew. If that is the case for you the following should work:
$ brew install libmemcached
$ brew edit php54-memcached
// you'll need to add the line:
args << "--enable-memcached-sasl"
// to the brew file.
$ brew install php54-memcached
Now to actually use SASL support, here is a test file that demonstrates it and is a good sanity check.
<?php
/**
* Test of the PHP Memcached extension.
*/
error_reporting(E_ALL & ~E_NOTICE);
$use = ini_get("memcached.use_sasl");
$have = Memcached::HAVE_SASL;
echo "Have SASL? $have\n";
echo "Using SASL? $use\n\n";
$mc = new Memcached();
$mc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mc->setSaslAuthData("user-1", "pass");
$mc->addServer("localhost", 11211);
$mc->set("foo", "Hello!");
$mc->set("bar", "Memcached...");
$arr = array(
$mc->get("foo"),
$mc->get("bar")
);
var_dump($arr);
?>
Adapting this to work in the Zend Framework is unknown to me right now. I'm not familiar with it so may take me some time to install and figure out. It seems very doable though given one of the backends works with SASL auth.
What is the difference on a Wamp or Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
And the reason I ask is I have a bunch of live websites that use the $_SERVER['DOCUMENT_ROOT'] definition.
On the live websites, $_SERVER['DOCUMENT_ROOT'] works perfectly.
On wamp server locally, it shows $_SERVER['DOCUMENT_ROOT'] as C:/wamp/www even though I have virtual hosts set up. Everything on wamp works except for the $_SERVER['DOCUMENT_ROOT'] declaration.
I used a php script suggested as a fix. The prepend_script set in auto_prepend_file in php.ini:is as follows:
auto_prepend_file = c:/wamp/www/prepend_script.php
$basePath = dirname(__FILE__); // assuming this script is in c:/wamp/www
$projectPath = preg_replace('#('.$basePath.'/[^/]+)/.*#i', '\\1', $_SERVER['PHP_SELF']);
$_SERVER['DOCUMENT_ROOT'] = $projectPath;
What that did was change the$_SERVER['DOCUMENT_ROOT'] from C:/wamp/www to /itsaboutwirelessnetworks/index.php
When in actuality for it to function properly it should be C:/wamp/www/itsaboutwirelessnetworks and not /itsaboutwirelessnetworks/index.php as the prepend script did.
So in order for myself and others to understand how this can affect them, I would appreciate an explanation of why it works on my live server and not the wamp server.
Hence the original question:
What is the difference on a Wamp or Live Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
The documentation says about DOCUMENT_ROOT: (emph mine)
The document root directory under
which the current script is executing,
as defined in the server's
configuration file.
So you should look at your config file and check if there is something strange there i'd say.
(I think that unless you've changed it, C:/wamp/www sounds like a valid value to assign to your document-root. If it should be something else, that must be defined in the config of the virtual host)
This seems like a bug in Apache, as it's defined in the Apache httpd.conf file.
http://www.devcha.com/2010/02/solved-incorrect-value-for.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=26052
Apache/php/mysql websites are most often run on Linux servers and you're developing on Windows, the large differences between them could well account for the different bug behaviour.
I've set up multiple vhosts under apache2 / mod_perl. I used the ErrorLog directive to get a separate error log for each vhost. This only worked as expected when I used Apache2::Log. 'warn' would only log to the regular error log.
So that's all working. Finally. But there's one issue remaining: When I log via $r->log_error, I find that newlines are replaced with \n
Any idea why this happens, and how it can be fixed?
Thanks.
This is not a mod_perl problem, but an Apache one. Apparently there are some security concerns with printing unescaped output to the error logs (I'm not entirely sure why) so you have to explicitly enable this in Apache when building/configuring it using this:
CFLAGS=-DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure
If you're using an already installed apache, there's not much you can do to change this.
If you have a pre-built install, you can use this line of code to fix the issue but it must be included in every page execution within your vhost, say in a header.php or config.php file.
ini_set('error_log','/var/log/apache2/error.log');
i know this is very old thread, but still coming on top on google results, so just to help all, the following changes in mod_perl.pl did helped me:
comment out below:
BEGIN { *CORE::GLOBAL::warn = \&Apache2::ServerRec::warn; }
the above is for:
Make warnings go to the virtual host's log and not the main server log.
i hope this helps anyone out there like me :)