I just moved my project to new server and after that I'm getting this message:
Whoops, looks like something went wrong.
I've changed permissions to "storage" folder and sub-folders... to 777 and nothing changed...
I wanted to see the logs... but even with 777 permissions there is no log file... :/
I also tried to get more details from the error by setting debug mode to true... but it changes nothing... :/
What needs to be done after moving files to server? Do i need to change some config to make it work?
I did the same with clean installation of Laravel 4.2 and i got the same problem... :/
UPDATE:
Actions made after installing new laravel 4.2 instance:
check i its working ("You have arrived.") so it's working.
create "app/config/production/app.php" (with debug => true)
transfer all files through ftp
change permissions to 777 for storage dir
check if its working: ("Whoops, looks like something went wrong.") its not... :/
page is here...
http://dev.slashlab.pl/lara-test/public/
(if this can help with anything... :/)
I hope this doesn't sounds too bananas -- but are you sure you're uploading and working in the right folder? If you've both changed the permissions on your files, and edited the debug configuration in all your app.php files to no effect, one possibility is you're editing the wrong files.
There are (mostly) 2/3 places, where your configuration could be. app/config/app.php , app/config/local/app.php and app/config/production/app.php. If you set debug to true in this 2/3 places and then upload them, it is not possible to have this error page. After upload, try to download it to your computer and check the file (is it correct).
So... after a long struggle... I found a solution... ;)
The problem was that on remote host i had magic_quotes_gpc turned on
Everything started to work flawlessly after turning it off. (same for laravel 4.2 and 5.0).
Thanks to all that helped, because every little answer pushed me few steps forward. :)
Related
So, i have this issue where I've uploaded a web page and some supporting files (css, images, etc) - but when I make changes and upload the files, the changes don't show up.
I've tried clearing my local cache, deleting and re-uploading files, and even went into the server's cpanel (I have access to the WHM and backend) to do it directly through the file manager. No changes are taking effect.
I went through and checked the source code to the css file and it's not the same as what I'm uploading.
Is there something I'm missing? Is there such a thing as caching on the server? If so, how do I empty the cache, or fix the issue?
I'm kind of desperate.
Thoughts?
OK! As it stands - I have solved the problem.
The issue was SiteLock Security. It caches a great deal of information that we don't want. While on the phone with support, they ended up showing me how to get 1) purge the caching, and 2) change the settings for caching specific information.
I DO want to thank you all for your input. I DID lead me down the right path. Kudos to you!
Thanks, again!
-mb
I was developing as usual on my Laravel project tweaking with the Queue driver settings in my .env file, when all of a sudden a random forward slash appeared at the top of my project which caused some random issues. I've cleared all cache's, routes, views etc but I am still getting the strange forward slash. I even get it in the console when I run a command.
Every page:
I assume its some kind of strange bug in Laravel. Hopefully someone can tell me whats the issue. Thanks in advance.
check you files in the config folder: app.php, database.php, ... and also public/index.php and look for a \ before the <?php or if you closed it somewhere.
if you find nothing, lookout for an echo in those files. (on windows use grepwin for fast search)
So I have been given the task of upgrading one of our companies' old websites that is based on 1.5 to something newer (because a second site of ours on the same version just got hacked).
I know some php and some other web stuff, but I'd never used Joomla.
I have setup a lamp server on a local VM (ubuntu) for me to test it all out on, then upload the upgraded version as is suggested. My problem now is that I know the permissions are not correct because when I tried installing Akeeba Backup, it kept throwing errors such as "could not copy to /var/www/components and /var/www/administrator etc. I went in and chmod'd those 2 (and then the rest of www because of more errors) to 757 (from 755 for the most part) - which i know at that point might as well be 777. Then when I've tried to use Kickstart to restore from the JPA file I have, it just right away throws an error "could not create j_backup/ folder".
I know this slackening of all permissions on the root folder is wrong, but it was the only way to get it to 'work', which it's not even now, so my question is what did I do wrong in the setup and how do i fix it? I'm not great with Linux, but I'm thinking I have to make PHP owner of www? is that right? or terrible practice?
The other issue I see now is that I just installed the latest php and everything and I see Akeepa says not to use php 5.4... not sure how much of a problem that's going to be....
Some direction would be great because I'm more than a little lost.
Thanks!
This is certainly a headache. Most often, as you stated, the issue is the ownership of the files on your server. Files uploaded via FTP will be owned by your FTP user and may not be editable by the Apache/PHP user. Similarly, files created by installing extensions in Joomla! will be owned by the Apache/PHP user and your FTP user will not be able to modify them. Here is an article discussing the problem with a couple of possible solutions:
http://docs.joomla.org/Why_can%27t_you_install_any_extensions%3F#File_ownership_advice_from_ianmac
In the past, I have used an Apache Module called suPHP (http://www.suphp.org/Home.html) to solve this problem and keep it from reoccurring. suPHP executes PHP scripts with the permissions of their owners.
As for file permissions other than ownership, please refer to the Joomla! documentation for the correct settings: http://docs.joomla.org/Verifying_permissions. One quick way to handle this (if you can install extensions after correcting the ownership issue) is to use the AdminTools extension (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087). One of its tools ‘fixes’ the file permissions on your server by resetting them to the Joomla! default.
Good luck!
I suddenly can't save any files in any of my Xcode projects in my home directory. Not sure what caused this. Here's the error I'm receiving:
I don't think Xcode is correct, since I am the owner of -- and have read+write permissions on -- the affected files.
A few other fun facts:
I can edit these files in other applications as the same user, so the problem seems to be specific to Xcode.
Other users can create and edit projects in their home directory without issue.
Running Xcode as root (via sudo /Developer/Applications/Xcode.app/Contents/MacOS/Xcode) does allow me to edit these files.
chown, chmod -R 755, etc. on the directory containing my projects doesn't help.
Disk Utility > Repair Permissions doesn't help.
Reinstalling Xcode, clearing Xcode .plists, etc. doesn't help. Failing both on Xcode 4.1 and 4.2.
Thoughts? Hopefully I'm just missing something simple.
I've just run into this issue myself. No amount of rebooting fixed it for me. In fact, it only began after a reboot. After much frustration, I used fs_usage to observer the file system calls that Xcode and any other processes were making when I attempted to save.
The results were interesting. In particular, one of the last things I saw before Xcode loaded NSAlertPanel.nib (which I assume is the UI for the error sheet), thing showed up:
revisiond.3029 getattrlist /private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems
Xcode.2437 mkdir /private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems/(A Document Being Saved By Xcode)
This looked highly suspect to me, so I investigated this directory. It turns out that
"/private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems" was owned by root:staff, and NOT writable by the group. Making this directory writable by the group fixed the issue for me immediately.
So, it appears this was a bad iteration between Xcode and revisiond, which is responsible for the File Coordination features in Lion. I do not know why this problem persisted for me when a reboot fixed it for others.
Check how you have this setup in source control. I've noticed with the new Xcode that if you have this under source control (svn) that that might be blocking your ability to write over the file regardless of permissions.
You may want to do an svn cleanup
from terminal issue a
ls -laE#"
There may be extended attributes or ACL (Access Control List) permissions problems. I have had that happen. It can be really bad if it has inherited attributes
If that is the case fix with
chmod -R -N
Be careful!
Looks like I had netbiosd blocked in my firewall configuration. After unblocking it and restarting my computer, the issue seems to be resolved.
I spent about two hours with this same problem. I tried all of the above. Finally, I rebooted my machine. Everything works fine after the reboot.
Everything was working fine and i ran into this issue. I tried most of the above suggestion. Finally,the MacOSX software update resolved the issue.
I have a problem with Magento after move it from local to live server: Magento connect is not working properly. I will explain it:
I have access to Magento connect, but the extensions are not working.
I have tried to delete the pear.ini file but didn't work. I have tried to delete the app/etc/local.xml file, copying the following files from a clean installation: clear, pear, peardev and pecl, and then running the installation process again, but nothing happened.
Is there a way to get my downloaded extensions working wihtout do a clean install?
Greets to all and I aplogize for my English.
Moving a Magento installation can be difficult. Here is the procedure that I have used many times with great success.
Make sure that your /download folder and the /pear folder are owner and group writeable and that the apache or other http user have write access via the group permissions.
Check the file permissions match the webserver's user and delete downloader/pearlib/pear.ini. When you hit the page, it will regenerate the file with the correct paths.
In order to get the extensions working I needed to copy all files manually. I don't know why, but I have tried everything and it was the only solution that worked for me.