im trying to get Varnish and Drupal work together. Im using the Drupal-Varnish-Module and i see that the server can be reached over the modules admin panel. I also put the necessary lines of code in my settings.php
$conf['cache_backends'] = array('sites/all/modules/varnish/varnish.cache.inc');
$conf['cache_class_cache_page'] = 'VarnishCache';
$conf['page_cache_invoke_hooks'] = FALSE;
But still no varnish-caching takes place as i can see in with the shell-command "varnishstat" and also via http://www.isvarnishworking.com
Any idea what the problem could be? Im thankful for any hints!
Regards,
Fab
Related
I run PHP 5.5 locally and 7 on live server. The trouble is with laravel session library where I am setting a session variable conditionally and then updating this where relevant. this works like charm locally, however the variable does not seem to update once set on the live server.
Does anybody know of something like this being affected by PHP 7. This is the only thing I can think of that would affect this bug.
if(in_array($currentState, Site::config('config.extra_delivery.'.$countryId.'.values')))
{
$newfulfilmentHouse = kohana::config('config.extra_delivery.'.$countryId.'.fulfilmentHouseId');
Session::set('amendFulfilmentHouse', $newfulfilmentHouse);
echo true;
}
else
{
Session::set('amendFulfilmentHouse', $origionalFulfilmentHouse);
echo true;
}
The I have a very simple ajax call that check with this line:
if(Session::get('amendFulfilmentHouse'))$currenctFulfilmentHouse = Session::get('amendFulfilmentHouse');
The else in the first function is really just as a back up in logic really. should'nt have any impact. its more based on the config.
I have a Laravel site set up on a Homestead box, so I'm accessing it on sitename.app:8000. I have a route called "news" but when I try to go to sitename.app:8000/news I get oddly bounced out to sitename.app/news/.
If I change the routename to "news2" I can access the desired controller action as per normal at sitename.app:8000/news2. So somehow it's "news" itself that has become uncooperative - and I'm pretty sure that we aren't even getting as far as the NewsController, when I try to access that url.
Can anyone work out from these symptoms what might be going wrong? One "news"-related change I made at some point was to add $router->model('news', "App\News"); in the boot method of the RouteServiceProvider, but removing this doesn't seem to make the difference.
ETA: People keep asking for the routes.php file. I can literally remove everything from the file except
Route::get('news', function() {
return "hello world";
});
Route::get('news2', function() {
return "hello world";
});
and /news2 will work but /news will bounce me out. So I remain pretty convinced that the problem is somewhere deeper than routes.php...
I finally worked out what boneheaded action of mine had been causing this behaviour!
I had created a folder in /public named "news"... i.e. with the same name as an important route. Not sure exactly what havoc this was wreaking behind the scenes for Laravel every time a request for /news was being made, but one can assume it was nothing good.
Advice for anyone tearing their hair out over a route that "mysteriously doesn't work" - check your public folder for possible collisions!
This is a known issue Larvel missing port
The easiest way to solve this problem is to go to public/index.php and set the SERVER_PORT value.
$_SERVER['SERVER_PORT'] = 8000;
Don't forget to set the base url in the config if you are using links on website, the url generator uses the base-url defined in the config.
Last option is to change the vm portfoward in VagrantFile to point to port 80 and use port 80 for your app.
I'm using Laravel on MAMP PRO (PHP 5.4). Both are vanilla install and I got Laravel working okay.
Next, Installed Sentry.
Inside of a login function on controller:
$user = Sentry::authenticate($credentials, false); // this works. I can see the $user
But then upon an immediate redirect I use a filter:
Route::filter('auth.admin', function()
{
var_dump(Sentry::check()); // ** this gives me a bool(false);
die();
if ( ! Sentry::check())
{
return Redirect::route('admin.login');
}
});
So, I'm assuming that maybe there is a cookie that is not being set?
Solved...
For anyone else with this issue, this is a summary of the most common solutions on the Internet as well as how I solved my issue. I'm on MAMP/OSX, but this apparently made zero difference as I literally put up a vagrant/virtualbox and still had the same issue.
** Set 'domain' => 'yourdomain.com' in your config/session.php. EVEN IF YOU ARE ON A SUB DOMAIN like a.b.c.yourdomain.com, use ONLY the root domain (yourdomain.com) in your 'domain' variable as I just wrote it. ** This was my issue.
Make sure your session storage folder has write permissions.
Make sure you have a >0 lifetime in your session.php
Make sure you don't have whitespaces after any closing PHP which could cause the application not to shut down properly.
Try Switching between database sessions and file sessions.
As a last resort, try upgrade to 4.2, if possible. 4.1 had a known issue (as referenced in google).
Your issue is may no be with Laravel OR Sentry. It's probably a file or configuration issue as illustrated above. I pulled my hair out tracking this from Sentry to Laravel to Cookies to Session to Blah... Only to realize that it was finally a cookie issue which was caused by me not setting my ROOT domain (I was using the full
I have website made in php_fox framework and my client want some changes on website but he don't want that changes on his server directly so firstly i have install that website on my localhost. so is it possible to install that website on localhost??? because right now i am getting 505 internal server error :(
Thanks,
Ruchita
yes, you have just to activate rewrite_module in apache from apache module (wamp)
Please check your server.sett.php (\include\setting)
search $_CONF['core.url_rewrite']
value of this variable should be 2 at localhost
$_CONF['core.url_rewrite'] = '2';
Please check your server.sett.php (\include\setting)
change the following $_CONF['core.host'] = 'localhost';
edit this $_CONF['core.folder'] = '/'; to $_CONF['core.folder'] = '/<your_phpfox_dir>/';
and edit $_CONF['core.url_rewrite'] = '2';
Additionally configure database settings
Delete everything inside \file\cache
Now run the phpfox instance in your localhost.
I'm trying to use such function as apc.filter in APC.But all, that i have done, didnt work
There are 2 task that I should done.
1)Need to include 1 catalog for caching.My code in apc.ini
apc.cache by default Off
apc.filter = "+/path1/.*"
Such option doesnt work.It's still caching
2)Need to exlude 3 catalogs on the server that shouldnt be cached,for example my code in apc.ini for such task
apc.cache by default On
apc.filter = "-/path1/path2/.*,
apc.filter = "-/path3/path4/.*,
apc.filter = "-/path5/path6/.*"
Can somebody help me with it?plz
apc.filter does not work for absolute path
http://www.php.net/manual/en/apc.configuration.php#ini.apc.filters
You can try to enable/disable apc for particular folder by using .htaccess directives.
In my case I need to disable APC cache for whole site, so I put the following into root .htaccess:
php_flag apc.cache_by_default Off
And it works perfect.
I think you've made a typo: it's apc.filters not apc.filter
For an example of what you're trying to achieve:
apc.filters = /path1/path2/.*,/path3/path4/.*,/path5/path6/.*
should do the trick, with a default cache set to On.
I wanted to do the same thing for my development environment. Since both production and development code were there on the same server, I wanted a way not to cache "test" directory.
I tried using
apc.filters -/my loc/my_test/.*,-/full_path/my_test/.*
But this does not work. The simplest fix is to modify .htaccess in your directory that you want to block being cached
<IfModule mod_php5.c>php_flag apc.cache_by_default Off</IfModule>
And it works beautifully.:)