I need to use time zone PST for my application, so i have set these settings in .htaccess file of my zend project. --
php_value date.timezone "America/Los_Angeles"
But it is not being reflected in my project, when i echo the date it is showing me Indian time. What am missing in this please help me to know.
Ensure .htaccess files is of any use. It may be that your httpd is not even reading it (most likely) or it does, but ignores your php_value (less possible as it usually ends with error 500)
Related
I set opcache.enable=0 in opcache.ini
Now I want to enable opcache from my htaccess file using
php_flag opcache.enable On
But it is not working
Is there any way, I disable opcache in opcache.ini, and enable in my application's htacces file.
Thanks
The simple reply here is that you can't enable. OPcache is a zend_extension and as such can only be enabled at a system level. However, there is a simple wrinkle here in the opcache.enable is a PHP_INI_ALL directive and can be set to 0 anywhere either at a directory or program context. So having opcache.enable=1 in the system configuration and then setting
php_flag opcache.enable Off
should work, and this will disable caching for the scope of that request
Also read up on the directive opcache.blacklist_filename (which is a bit of a misnomer, BTW). This allows you to define files and file hierarchies that are not to be cached (but once blacklisted you can't then create exceptions or unblacklist files at runtime.
Also since the enable is a PHP_INI_ALL directive, there is nothing stopping you adding a bit of code logic disable caching for the scope of that request in an auto_prepend_file included script instead of using an htaccess php_flag directive, but not that once disabled, you then can't re-enable it, so you can only use the blacklist to control caching at a file level.
My php script that uploads files in my centos - apache server was working fine.
Today I enabled suphp in server and after that script is not uploading any files.
I was used "php_flag register_globals on" in .htaccess before. But I removed that line from ".htaccess" in order to prevent 500 server error.
Pls help
After a long search and testing, I found the solution myself.
Just created a php.ini file and added a line:
register_global = on
and removed all php flags in .htaccess.
Now its working fine.
As you figured out the parameter has to be in a php.ini file and suPHP has to be instructed to read this file. More information in this answer: php.ini not being read (Debian / ISP Config)
But; If your upload script requires register_globals to be enabled it's probably badly written or outdated. You should try to avoid using register_globals since it poses a security threat. More about that here: What are register_globals in PHP?
I am trying to get pretty urls using htaccess for SLIR image resizing plugin.
I want to rewrite something like below:
Before Rewrite:
localhost/img/600x400/slider/image.jpg
After Rewrite
localhost/application/public/slir/index.php?r=slir&w=600&h=400&i=img/slider/image.jpg
But the following code is returning a 500 Internal server error...
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)/([0-9]{1,4})x([0-9]{1,4})/(.*)\.(gif|jpg|jpeg|png) application/public/slir/index.php?r=slir&w=$2&h=$3&i=$1/$4.$5 [NC,NE,QSA,L]
</IfModule>
Please help me.....
UPDATE
I thought it was a File Permissions issue...
so I checked all the related directories and files, surprisingly there were all 755/644.
Then I directly checked the /application/public/slir/index.php. It was not accessible.
I created another file named hello.php in the same slir directory and hello.php was accessible.
Then I moved the SLIR directory to the another folder named public. Here, both the index.php and hello.php were accessible.
After that, I moved SLIR directory to back to the original scripts folder. In scripts folder, hello.php is accessible but index.php is not accessible.
Now, Both files have same permissions and are in same folder.. I dont know what is happening here... :/ :/
Someone please help me......
In case anyone else is looking at this - the problem I found was these two lines in the htaccess file:
php_value auto_prepend_file none
&
php_value auto_append_file none
some servers don't allow them.
moving them to my php.ini file solved it for me:
auto-prepend-file = none
auto-append-file = none
That is probably because you are editing the .htaccess file with a Windows based editor like notepad. Notepad adds some characters to the file which you can't see, but they mess with the .htaccess. I recommend using an editor like Notepad++ and setting the mode to Unix, so it won't mess with the server..
Speaking technically that is because Linux and Windows have different type of EOL ( End Of Line ) so that notepad adds some characters to the end of every line to go to the next line, but Unix won't recognize them, because it has it's own type of EOL..
Slashes are normally forbidden in query strings, but you can enable them by setting
AllowEncodedSlashes directive.
You may also want your rewrite rule to use percent encoding for slashes (that is %2F) so after rewrite:
localhost/application/public/slir/index.php?r=slir&w=600&h=400&i=img%2Fslider%2Fimage.jpg
See also How do you configure apache php to accept slashes in query strings
Duplicate, phrased very differently:
Has anyone used Smart Image Resizer on subdomain sites?
The problem is the subdomain...
I'm curently using PHP for uploading images to my server. But -obviously- there's a limit in filesize, and I can't modify the .htaccess file, and can't access the php.ini file..
What happens when I, for example, add:
php_value post_max_size 10100000
, and:
php_value upload_max_filesize 10000000
to the .htaccess file, I get error 500.. This error will stay until I put back the original .htaccess file..
Neither does making a new php.ini in my main folder, or using ini_set() in php help, so my question is: is there a way to upload bigger files without having to alter php.ini or .htaccess ?
thanks in advance,
Jeroen
If you cannot change those directives, there is not much you can do.
Maybe you could use some other language than PHP, for your upload components ?
Maybe a CGI written in Perl, for example -- there are still hosting services supporting those ; and they might not have the same limitations.
this is out of 32bit Linuy limit.
Try using
php_value upload_max_filesize 1500M
php_value post_max_size 1500M
Ok, I think I figured out what to do. I cannot use CGI or PERL on my host, so I got to stick to PHP, and thus I'm left with this memory_limit.. I don't know if ini_set() is enabled on my server, so I need to find a way not to overload the memory dedicated to each request..
What I'm planning to do, is giving every upload (and resize) request a new, fresh page.. So each upload will have it's own iframe!!
This worked in Chrome so far, will test it later for other browsers, as I don't know if post requests will be accepted for iframes in every browser..
I know there are a lot of questions on here about this, but most of them seem to be from people who don't know that 'memory_limit', 'post_max_size', and 'upload_max_filesize' are PHP_INI_PERDIR (i.e. they can't be changed using ini_set()). I already learned that the hard way.
However, everything indicates that I should be able to change them using a .htaccess file—everything, that is, except my actual experience.
Here are the contents of my .htaccess file:
# Allow large file uploads
php_value memory_limit 4294967296
php_value post_max_size 1073741824
php_value upload_max_filesize 524288000
I've tried a number of different combinations, but none of them seem to have any effect on anything. I know I've gotta be missing something, but I can't for the life of me figure out what that something is.
P.S. I'm running PHP 5.2.4 locally on Mac OS X 10.4 from entropy.ch.
You need to permit those settings to be changed in a .htaccess file. For that, you need AllowOverride Options or AllowOverride All in a relevant section your httpd.conf file (in a <Directory> block for that directory or a parent thereof).
Note also this will only work if you're using Apache and mod_php5 (i.e., no CGI/FastCGI/whatever).
See also the manual.