I am trying to run Imagick within Laravel 5 and I keep getting this error every time I try and run my code. Imagick::paintTransparentImage method is deprecated and it's use should be avoided. Before when I was running the code without Laravel this was a warning but the function would still run. Is there any way to suppress or turn off this warning? All other Imagick functions work great, and this one does if run outside the context of Laravel.
as you mentioned, Imagick::paintTransparentImage method is deprecated.
Use Imagick::transparentPaintImage instead.
http://php.net/manual/en/imagick.transparentpaintimage.php
I ended up turning turning down the php error reporting strictness and the code runs fine. If anyone else gets this message do not freak out, it is depreciated but they have NOT provided an up to date alternative, opaquePaintImage is NOT the same thing.
Related
Normally executing echo stripcslashes('Dr\xc3\xa4ger') should output Dräger but when I execute it on my production server with error_log(stripcslashes('Dr\xc3\xa4ger')) I just get Dr\xc3\xa4ger in the Apache error log.
Can someone please tell me why?
So here's what's happening, stripcslashes('Dr\xc3\xa4ger') is indeed doing the job you're asking of it, returning Dräger. However Apache is apparently re-escaping it prior to writing it to the error log, which is why it's showing back up there as Dr\xc3\xa4ger.
(I would not recommend recompiling Apache to disable this, as is recommended elsewhere online.)
Any need to verify that this conversion is happening is something that should be covered by your test suite. (Your tests which cover whatever relies on this, I'm not suggesting you individually test built-in PHP functions.)
I'm trying to migrate a script in php 5.2 to 5.5 that uses set_magic_quotes_runtime() to disable them. I found a hint that suggested I could replace it with:
ini_set ("magic_quotes_runtime", 0);
Is this correct?
Simply delete the line.
Magic quotes have been dead for some time, and have been removed in PHP 5.4 and later. There is no reason to force them to off when they don't exist.
If you are trying to turn them off, there's nothing to be done - the feature has been removed from PHP entirely since PHP 5.4. There's no need for the line you cited at all in PHP 5.5.
If you are trying to turn them on, you would need to recreate the feature in userland using something like str_replace(); however, I would urge you not to do it.
I inherited some PHP source code, and I have to maintain it. It has been built from scratch using no framework, just the former developer's own creation.
Now, I ask this:
Is there a way to ignore fatal errors in php.ini/ini_settings only without modifying the code?
Scenario:
SomeClass.php:
<?php class SomeClass {
...)?>
index.php:
include("SomeClass.php");
...
include("SomeClass.php");
In my development box, this throws a Fatal Error exception (because SomeClass has been declared twice), which is the obvious and expected behavior.
Here is the kicker: This source is hosted somewhere, and it works. I just don't ANY access to that server.
So I see here two scenarios:
1.) There is a way to silence this Fatal Error via 2 includes by an ini setting. This I have to know.
2.) The former developer did NOT give me the exact, updated source code that is currently up and running. I then have to insist that he give me the latest source code, but I can only do this if I am 100% sure that there is no way #1 can happen.
What do you guys think?
I tried setting a set_error_handler() function that doesn't die on fatal errors, but instead Apache crashed. In other words, PHP needs to die so that the system doesn't.
So, sorry, I really don't think there is a solution for that.
Fatal errors don't come from the include function - only warnings. You'd get fatals from require, though. Use #include and it won't even generate the warning.
Error reporting is mostly discouraged on production servers. Why let the user see if your script didn't find a file. Have a look at this http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors and http://www.php.net/manual/en/function.set-error-handler.php. The latter could be helpful, go through the page for examples. I suggest to log errors instead of displaying it. But that will involve some sort of workaround with code.
inform your developer that he should use __autoload or spl_autoload to avoid such errors…
So I was reading about PHP namespaces, and I realized that in versions earlier than 5.3, if you write
namespace MyNamespace
you get a parse error.
Is there any way to avoid this i.e. make namespaces backwards-compatible, so the code doesn't simply crash?
Short Answer: No.
Longer Answer: (added to capture useful information from other deleted answers). The new Syntax will cause parse errors in PHP, so you can't use a customer error handler to catch errors generated in versions < 5.3. In theory you could write a pre-processor the scans and/or does a lex/parse on the source and then write something back out that would be PHP 5.2 compatible, but that creates more problems than it solves.
Perhaps you could query the version of PHP being used and call eval if it's high enough. I don't know if that will work though.
Actually, I think it's possible, but I don't believe it's worth it. The idea would be to create a custom default stream wrapper, which will parse PHP files according to the new grammar and make the appropriate changes to the syntax so that it will be valid PHP < 5.3.
The wrapper would have to replace class names such as Foo\Bar\Baz with Foo_Bar_Baz. Currently I'm not sure if there's something that would render this impossible.
Anyway, I don't believe it's worth the effort. Upgrade to PHP 5.3.
Oh, that means that the wrapper code should be compatible with PHP < 5.3.
I know this is a very old question, but I needed to make a couple of instructions with namespaces backward compatible with a very old PHP installation (5.2).
What I finally did to avoid parse errors was:
if(version_compare(PHP_VERSION, '5.3.0') >= 0) {
include("file_with_namespaces_code.php");
}
else{
echo("put php 5.2 code here");
}
I ran across an interesting issue today. We have an application that utilizes Zend Frameworks caching functionality. A request to this application typically calls a factory method using the following line
$result = call_user_func_array(array("myclass", "factory"), array($id));
The idea is to return an object from the factory method that we can access later on. When we implemented a caching feature, this call just, well, dies. No errors, just a white screen. Nothing in the error log. We can error log the line before ok, but trying to error_log inside the factory method does nothing.
Interestingly enough, changing the line to :
$result = call_user_func(array("myclass", "factory"), $id);
fixes the issue.
We've spent a few hours looking around for bug reports and haven't come up with much to explain this behavior. Thoughts anyone?
I have had issues like this that came down to __autoload not firing properly when a not-yet-loaded class was invoked through a PHP command. No other strategy than dumb trial and error for it as far as I know, just try if a line explicitly invoking the class before the PHP command solves it for you.
$dummy = new MyClassName;
call_user_func_array(array('MyClassName', 'method'), array($id));
unset($dummy);
Which version of php are you using? There was an issue in combining call_user_func_array with ReflectionClass at one point. I'm not sure if it's fixed yet.
Is it segfaulting? Check your 'root' apache logs (outside of any virtualhost) and see whats going on. If that thread is segfaulting you may want to persue that on the PHP mailing lists and/or bug tracker.
Alternately you could try running http in single user mode, in GDB, with a debug-compile of php and see if you can capture it, but thats a lot of work :-)