In symfony2, I'm using the liipImagineBundle to produce thumbnails on the fly. It used to work perfectly on my local server but I've been having trouble after hosting the site of a shared server. I've been experiencing the same problem as described here and here, that is, the source is http://my_domain.com/media/cache/resolve/my_thumb/uploads/images/entry/DSC_04121.jpg instead of http://out-of-the-nest.com/media/cache/my_thumb/uploads/images/entry/DSC_04121.jpg.
Thanks to those two questions, I know where the problem stems from but the solutions proposed are no help for me. I don't have accessing to the configuration files, or to php.ini. I've tried changing the permissions of the cache with filezilla but it doesn't change much. Also, as mentioned in the symfony2 documentation, I've tried using umask(0002); and umask(0000); in app.php and app_dev.php, to no avail.
I'm really not sure what to do here, can someone help me?
Edit
Turns out it might not be a permission issu after all. Symfony throws a NotLoadableException: Source image not found in "/home/outoftheoo/app/../web/uploads/images/entry/DSC_04121.jpg" which is to be expected because the web folder doesn't exist, I renamed it www because that's what ovh expects. I did configure liip so that it would know (I think anyway) by putting a
web_path:
web_root: %kernel.root_dir%/../www
cache_prefix: media/cache
in config.yml but it doesn't seem to be enough
P.S: If it happens to be relevant, the shared hosting server in question is provided by OVH.
Edit 2
Found the problem. config.yml was missing a:
loaders:
default:
filesystem:
data_root: %kernel.root_dir%/../www
The resolve you are seeing is normal for the first time liipimagine needs to create the thumbs url, so it is not an error in the image path(empty your web/media/cache directory on your local and refresh and you will see it there too). The fact that it is failing to create the thumbs is why you keep seeing the resolve.
What does the app_dev say when you use the resolve link? enable it for the remote host and check
Related
I'm currently working on symfony2 projects. Each time, the deployment process is a real pain in the back (even with the cookbook advices).
I have this strange feature that I can't explain. My post variables are always empty in some bundles of symfony 2, no matter how I access them ($_POST['foo'] or request->get('foo')). This feature is online only. On my local server, it works perfectly well.
Example 1: coresphere console bundle
I'm using the coresphere console bundle to run command line on my ovh remote server. But the bundle commands were never working (no matter what my installation was) ie my post variables were always empty causing each command to crash. I thought that may be an error in some of my other installed bundles was causing the post variables of the console bundle to be empty. So I installed it on an empty symfony2 project (I even removed Acme and of course I tested that everything was working on my local server before uploading the project). The console still didn't work. My only solution (a bad one though) was to hack the javascript console.js of the bundle and transform the post request into get request. It then worked fine. At this stage I thought: "ok may be the problem comes from ajax post request on ovh?"
Example2: A home made bundle for a project
I build a bundle for a project. In this project I don't use ajax post request at all. And still, my post variables are always empty (I remind that locally, everything works just smoothly). For this bundle I'm using FOSUserBundle with HWIOAuthBundle for authentication (if it has anything to do with that?)
Summary
I'm clueless about what is going on and I would like to have some sort of track to follow. Just as a reminder: I'm using an OVH shared server with the performance package. I can use git up there. But I can't really use console command (even in ssh). So that's why I'm using the coresphere console bundle.
Thank you for your help.
I got a solution for my home made bundle:
The problem was coming from my routing.yml file (in app/config). I was using fosjsrouting and it seems that the routing of fosjsrouting needs to be called at the very end of the routing.yml file (in app/config).
See below:
app/config/routing.yml:
... and at the very end:
fos_js_routing:
resource: "#FOSJsRoutingBundle/Resources/config/routing/routing.xml"
However, I still don't understand the problem with the coresphere bundle. This doesn't solve it.
In my site i am getting problem as like following.....
Warning: getimagesize() [function.getimagesize]: URL file-access is disabled in the server configuration in /homepages/46/d390162509/htdocs/public_html/sugapps/wp-content/themes/grizzly-theme/base/shortcodes/image.php on line 89
Warning: getimagesize(http://www.sugapps.com/wp-content/uploads/2012/02/2806313447_2900756f3d_b.jpg) [function.getimagesize]: failed to open stream: no suitable wrapper could be found in /homepages/46/d390162509/htdocs/public_html/sugapps/wp-content/themes/grizzly-theme/base/shortcodes/image.php on line 89
I am trying various way but I am not succeeded . It's working locally as well but looking problem in server. Also I have no php.ini file Becaused it's sheared hoising....
If it's possible for anyone to solve this or give me any well information to solve this problem , I will pleased with you. If you want to see this problem in my site, you can visit: http://www.sugapps.com/
I understand this error to be related to a setting in the php.ini file when allow_url_fopen and or allow_url_include is set to OFF. If it's possible for you to host the file(s) locally, that would be best. Assuming by the file path it's a theme, that shouldn't be a problem. Good luck!
This means that the hosting company you are using has disabled this feature in php, you can not do it. I suspect it's turned off specifically for remote files since many hosts turn that off.
I encountered the same issue. I am going to inquire with my 3rd party web provider but I also found a work around. That is have all *.php files in the same directory.
I'm using Dreamweaver (CS5) to manipulate a Wordpress template, however when I try and use 'live view' on a themes index.php file I receive the error:
"Dynamically-related files could not be resolved because of an internal server error".
My local host however appears to be working fine and correctly displays the index.php file located on my top tier directory.
Many users have resolved this error by turning perma-links to default, however mine are already set this way.
Any help would be appreciated.
This isn't a solution, but merely a reference for someone else who is having a similar issue.
I had the same issue using the /%postname%/ permalink structure, but when I returned to the "Default" structure, it discovered the files fine.
If you're just testing a design before implementation, I suggest leaving it to "Default" on your testing server. Or, if you haven't already, create a testing server.
I had the same problem i fixed by changing Permalinks to custom structure and below there is Option ->category base give a name and try it. Dreamweaver knows all dynamically related files after all.
Selecting default permalinks structure also works on DW CS5. Hope this helps.
I recently moved my Drupal 7 site to a new hosting server and I'm stuck at the login page. As soon as I try and log in, I get directed back to the same page, but the URL changes from /user to /user/1, which leads me to believe that I am actually logged in, but I'm not being forwarded to the correct page.
I tried cleaning my cache, emptying the cache tables in the DB but nothing helped.
Any ideas?
EDIT: To make things a bit more clear, I've used the specific server for various other Drupal 7 sites, so I know for a fact that the server configuration is not at fault here.
I suspect your $cookie_domain in /sites/default/settings.php is incorrect.
Try making it match your new domain and ensure there's a leading dot .
$cookie_domain = '.mydomain.co.uk';
Sometimes problems relating to logging in after a site migration can be because mod_rewrite was enabled on the first machine but not the second. A simple way to test this is to use the ?q= URL format (http://site.localhost?q=user) and see if you can log in like that. If that works then you can either disable clean urls from within the Drupal interface, or enable mod rewrite in Apache.
In my case the issue was solved only after refreshing .htaccess file in drupal root folder.
You can take the source here: https://github.com/drupal/drupal/blob/7.x/.htaccess
seddonym's comment about mod_rewrite led me to a slightly different solution. I was having the same problem but was able to solve it by copying the file rewrite.load from /etc/apache2/mods-available to /etc/apache2/mods-enabled.
I think the files in mods-enabled are some sort of link files (I am novice at linux still) but copying the files worked just fine. Maybe someone will come along and tell us the proper way to do this.
Sometimes all you need is to clear the cookies for the domain/website - it's possible you have old cookies alive that are causing this.
Get a cookie manager to help simplify this, e.g.:
Edit This Cookie (for Chrome)
Other answer might be that rewrite php module is not installed, to do that do the followings:
sudo a2enmod rewrite
Restart apache2
sudo service apache2 restart
In my case it was very stupid, on my page.tpl.php, there wasn't any "content" and the page--user.tpl.php didn't get read. Only had the line to show content in the page.tpl.php
Although that it is unlikely that you're as stupid as me. ;) Maybe it will be helpful anyway.
Arne
I am getting this error message while trying to access a wordpress blog which is installed in a directory. Is this due to .htaccess or something? Any help is appreciated.
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#xxxxx.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at xxxx.com Port 80'
This is almost always a problem with your Apache configuration. Errors originating in PHP won’t trigger the Apache 5xx handler, which is what you’re seeing.
Unfortunately, without more information, your problem is impossible to diagnose. I’d recommend that you:
Check the logs. First thing! It should give you a better idea where your problem is.
Stop and restart Apache. If there is a problem with permissions on something Apache needs write access to (logs), it could completely fail to start. This should give you the proper motivation to fix the problem, particularly if there are other VirtualHosts on that Apache.
Move your .htaccess file(s) somewhere else. If Apache works, you know it’s a problem with that file.
It sounds like you're getting some sort of PHP error but PHP isn't set to display errors. You'll want to check your Apache logs for detailed error info.
The mostly likely culprit is that you're missing some prerequisite for running WordPress, although all you should really need is Apache, MySQL, & mod_rewrite.
I was able to fix it by adding the following line to my .htaccess file:
php_value memory_limit 128M
Russ
This is happening to me RIGHT NOW.
As to from what I know, my hosting providers did a DNS change and so I'm waiting for the DNS to propagate, it's been like three hours and still zero.
Blog is showing ok, apache is up and working, I just can't get access into the WP Admin area.
If it does get fixed by tomorrow, I'll reply here so it can be of help for others.
Edit: I just fixed my problem.
In my case it was determined that the Fast Contact Form plug-in was creating the problem. I modified the folder name from si-contact-form to si-contact-form-hold then I regained WP Admin access.
After that I created a php.ini file with this string inside 'memory=64MB' and saved that into the wp-admin folder.
Manually deleted the si-contact-form-hold (to avoid possible corrupted files) and reinstalled the Fast Contact Form.
All my settings were already there and everything is back up and running good!
Hope this helps.
Look at http://zemalf.com/1470/wordpress-htaccess-the-definite-guide/, and look for the paragraph which says something like "Good and default .htaccess looks like this...."
My issue was a little bit different. I had an .htaccess file inside the wp-admin directory. I deleted the .htaccess inside of wp-admin and that fixed my problems.
Unfortunately it could be anything. Do static pages on the site work properly.
Have you checked the server logs.
I think it is likely to do with php. If static pages are there then possibly your config for wordpress is incorrectly configured or files missing.
Has php be working? Did the blog work and then stop? Did you get through the install process?
Check wordpress files ownership for the user are correct or not.
In linux ls -laZ command will display the ownership.
For setting the ownership for a folder use this command
chown -R username:username /user/username/public_html/
An HTTP 500 error could be caused by a great many things. Have you changed your .htaccess file recently? If you try to use a .htaccess feature that is disabled on your host, that is one possible cause.
Some more points
Blog has been running successfully. Just observed this problem since yesterday.
Blog is in a directory so it works something like this www.xyz.com/blog. Apparently www.xyz.com is working perfectly.
Update on logs
Getting these two errors in the logs:
File does not exist: /home/directory/public_html/500.shtml
/home/sub-directory/public_html/sub-directory/.htaccess: RewriteCond: bad argument line '%{REQUEST_FILENAME}!-f'
/home/directory/public_html/sub-directory/.htaccess: # without matching # section
How do I restart apache on cpanel ?
memory = 64MB;
The above line inside a php.ini file uploaded to the wp-admin folder solved my problem. I was not being able to log into the dashboard either through /wp-admin or /wp-login.php, and was getting a HTTP server error 500.
There can be multiple causes for this, I just solved mine, after 2-3 hours of going crazy.
I had another WP instance in a subdirectory inside the main WP instance (in the root folder).
Have checked / deleted .htaccess
deleted plugin folder
In the end, it was to do with the permission of the subfolder in which second instance was running. It was originally 775 (write permission for group), I had to change it to 755 (no write permission for group) and this finally fixed it, like magic.
This is of course just one of possible the answers to your question, I wanted to write it down though as I didn't find it explicitly written anywhere so it might save others some time.