Loading Profile...
Help get this topic noticed by sharing it on
Twitter,
Facebook, or email.
Twitter,
Facebook, or email.
I’m
confident
Wygwam file browser is disabled?
I updated Wygwam, fieldframe and FF Matrix (1.5 ) to the latest version and now get this error when I try to browse the server through Wygwam "The file browser is disabled for security reasons. Please contact your system administrator and check the CKFinder configuration file"
Promoted
Response
-
3Josh - check that you are accessing your CP on the same domain as per your EE settings - i.e. it wouldn't work for me when I was accessing http://domain.com whereas in the settings the URL was http://www.domain.com
-
Are your Themes folder URL and Fieldtypes Folder URL on the same domain that you’re accessing your site from? (www vs no www, etc.)Comment
-
-
Yes, both are on the same domain
Fieldtypes folder URL: http://cms.mydomain.com/system/extens...
Themes folder URL: http://cms.mydomain.com/themes/ -
-
Odd. Can you email me super admin and FTP credentials? Not really sure what else could be wrong off the top of my head.
-
-
Would be very grateful if you could take a quick look, have mailed you.. oops, don't have ftp info on me tonight, will resend tomorrow. Thanks.
-
-
Have resent you the info you'll need. Thanks again.
-
-
I’m
relieved
Creating a new weblog somehow fixed the problem, I can now browse again. -
-
I'm having this issue as per this:
http://help.pixelandtonic.com/brandon...
There doesn't seem to be any logic to why it doesn't work, and I can't keep on recreating custom fields and blogs every time it fails....
There's definitively an issue with 2.0 here... -
-
try to set your CP Home › Admin › System Preferences › Security and Session Preferences >> Control Panel Session Type to "Cookies only".
This solved the problem for me, it was more a proxy than a finder problem. -
-
It didn't help unfortunately. I have just reverted to version 1.3 and it works perfectly again. Some problem seems to have crept into 2.0.
-
-
I’m
confused
Brandon I have a client that is getting this but I am not. Same credentials (super admin). Same site. Same everything. I don't get it. Any ideas? We also have the Session Type set to Cookies Only. -
-
I'm seeing this behavior also. Let me know if you need our info. -
-
You may want to check out this other thread. Seems that there may be some path issues.
http://help.pixelandtonic.com/brandon...
I have not figured out whether that is our issue or not because as I stated before I am not seeing the same thing that my client is seeing... and he is out at the moment. Will report back when he gets a chance to test.-
did you figure this out for your client? I'm seeing the same thing with one of mine. We actually have several users on the site and for a couple of us it works just fine, but others get the error and cannot upload images. Ugh.
-
-
Umm... nevermind. I just discovered my client's writer was still using the development domain, not the live one.
-
-
-
-
-
I am seeing this issue now. One common thing I see is that this seems to be happening with sub domain urls only. Am I correct in saying that? -
-
-
-
I have the same problem too. I tried cookies but nothing.
I'm running from MAMP and the domain follows - is http://domain.local -
-
WTF? I have one site that behaves fine and another that throws this error. All permissions are the same. Both are hosted on MAMP...
-
-
This is the fundamental problem with me - it works beautifully on some sites, and not at all on others, without any obvious differences in server, EE installation, etc... -
-
Absolutely no idea how but everything started working again.
-
-
I'd just like to add that I'm having the same problem and it seems sporadic. Sometimes it gives me this message and sometimes I can browse and upload files. I really need a fix because I have a client waiting and this is our final holdup. -
-
3Josh - check that you are accessing your CP on the same domain as per your EE settings - i.e. it wouldn't work for me when I was accessing http://domain.com whereas in the settings the URL was http://www.domain.com
-
-
Man, that seems to be the problem. Thanks so much for the quick reply.
-
-
EMPLOYEE
2First, you should be *forcing* either www or no www, via a redirect.
To force no www, add this code to your .htaccess file:
# force no www
RewriteCond %{HTTP_HOST} ^www [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
If you do want the www in there, use this code instead:
# force www
RewriteCond %{HTTP_HOST} !^www [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]
Then go to Admin > General Configuration > System Preferences and make sure that your Site URL and Themes Folder URL settings both use the correct domain. And if you're using EE1, go to Admin > Utilities > Extensions Manager > FieldFrame Settings, and make sure your Fieldtype Folder URL is also set to the correct domain.
(Root-relative URLs also work, e.g. "/themes/", but not recommended for the Site URL, since that setting is used within EE-generated emails, etc.)-
I may be stating the obvious because I'm an idiot, but I think one additional line is necessary at the start of both these snippets of .htaccess code:
RewriteEngine On -
-
-
-
-
Thanks for the detailed reply, Brandon. That was really helpful. I appreciate the top-notch customer support you're providing.
-
-
I’m
anxious
I'm having the same problem, it was working fine, and now it doesn't... I followed the instructions but that didn't solved the problem.
I must launch the website this week, I don't understand what's going on with this add-on... -
-
I’m
happy to help.
Hey, Sylvain. I understand your frustration.
I'll give you a detailed explanation of how I worked out my issue because I don't know that anyone's posted it yet in extremely clear language.
Let's say the website I was working on was www.myexample.com. Whenever I would access the ExpressionEngine control panel I'd go to http://www.myexample.com/eesystem and type my username and password to log in.
The problem for me was that my system settings were set so that the URL to my "themes" folder didn't include "www" in it; when I was including the "www" in the URL to access my control panel I was getting this error because I was essentially going to a different address than I'd defined in my general configuration.
To test and see if this is your problem, log into your EE Control Panel and go to Admin —> System Preferences —> General Configuration. See what you have set for the "URL to you 'themes' folder". If the path includes "www" you'll need to log into your control panel with the "www" and if it doesn't, you'll need to log into it without the "www" or change the settings.
To solve my issue I changed my path to include the "www" and then used Brandon's .htaccess tip from above to force my client's website to always include the "www".
I feel like this was rather lengthy, but hopefully that helped. I'm happy to clarify further; I know how frustrating it is to be on a deadline and have technical issues popping up.-
Thanks Josh. I should probably just add a Troubleshooting section to the Wygwam Docs.
-
-
Thank you for your kindness. That unfortunately didn't solve my problem but thank you for taking the time to help me.
-
-
-
-
-
I can confirm that this doesn't necessarily fix the issue. I am forcing 'www', my Themes URL includes the 'www', and I'm still getting this error. (I also tried this with just '/themes/' in the URL path.
Also, I tested the "Cookies Only" selection in the Security Prefs (above) and that does not remove the security prompt.
Any other ideas? -
-
Hi Chris,
Other than the domain issue, the other common culprit is that your host didn't set up PHP sessions properly. There are a couple possible explanations for that, but most often it's because PHP doesn't have write permissions for the directory it's trying to save session data in. You can check that by creating a PHP file on your server with this inside it:
<?php echo (is_writable(session_save_path())) ? 'pass' : 'fail'; ?>
-
It fails. Bummer. 'Twas thinking about canning this poor host, but if the client puts up a fight, what is the request I make to the host to get this fixed?
-
-
Just let your host know that PHP sessions aren't saving, because PHP doesn't have write permissions for its session save path. Should be an easy fix for them.
-
-
-
-
-
I’m
unsure
I also get a fail, that should explain the problem. What I don't understand is that it was working before. I used it to load lots of images on the website.
What could have happened ?-
Are you getting the same error – "The file browser is disabled for security reasons..."?
-
-
Everything was working fine and then I got that error, don't know why... Your PHP file test report a fail on my server (I've put it in directory used by the file browser).
-
-
-
-
-
Brandon
I'm having this issue as well and I imagine it has to do with domains. I'm setup with MSM and have the following addresses in action:
http://domain1.com - Site 1
http://domain2.com - production version of Site 2
http://new.domain2.com - staging version of Site 2
http://manage.domain1.com - EE System
I'm trying to edit an entry from Site 2 (domain 2) from my EE System url (domain 1). The image upload directory is set to a directory that resides at domain1.com/images/uploads/ and is symlink'd to domain2.com/images/uploads/ and new.domain2.com/images/uploads/
What direction should I be going in figuring out a solution to this? -
-
All that matters is that your Theme Folder URL is using the same exact domain as the one you're accessing the CP from. Setting the URL to a root-relative path like "/themes/" will ensure that. And if you get 404s, you can just create symlinks of the themes folder across all of your domains.
-
-
Interesting. The paths are set correctly in that case.
I double checked to see if my session directory was writable and it is according to the server (770 permissions). However running the small function you have above tells me that it is not writable.
It's a MediaTemple (dv) server so I dug around in their knowledge base and found this: http://kb.mediatemple.net/questions/6...
I did what it suggested and unfortunately still get the error. Any other thoughts/ideas?
I'll keep digging but I thought I'd at least share that much.-
Does that little PHP script still say "fail"?
-
-
No, actually. Thank you for reminding me to check. It says 'pass' now.
-
-
-
-
-
Let's try another test, to make sure sessions are being retained between your CP and CKFinder.
Create this PHP file, saving it inside the system folder:
<?php
session_start();
$_SESSION['sesstest'] = TRUE;
?>
And then create this PHP file, saving it in /themes/wygwam/lib/ckfinder/core/connector/php:
<?php
session_start();
echo (isset($_SESSION['sesstest'])) ? 'pass' : 'fail';
?>
Point your browser to the first script (using the same domain you're accessing your CP with), and then point it at the second script. What does it say?-
I'm having this issue as well and have tried all of the above solutions. When checking if PHP sessions save properly it passes. However, when trying the above check inside the /themes/wygwam/lib/ckfinder/core/connector/php/ it fails. With that being the case is there anything else I can try?
-
-
If that test fails, try simplifying the test by moving the second file into your system directory.
If that still doesn't work, it means sessions just aren't getting saved at all, even though the session directory is supposedly writable.
But if it does work, the issue is that sessions aren't carrying from your system folder to your themes folder.
Either way, you should talk to your host. Show them what you've done and ask what the deal is. -
-
-
-
-
1Thanks Brandon. Turns out it was indeed an issue with the host, in this case Rackspace Cloud Sites. For reference in case anyone else runs across the same problem with them, they essentially store all session data across portions of the Cloud in the same global session file. This file can fill up which causes some sessions not to hold or to be removed. To remedy this issue you can store your sessions in a location of your choosing. More info can be found here: http://cloudsites.rackspacecloud.com/...
Doing this did indeed solve my issue.-
Casey, this totally solved it for me too. Thank you sooooo much!
-
-
-
-
-
Got one more thing to check - our fix ended up being embarrassingly easy but thankfully painless - our CP defaults to 'https' but the various path settings used 'http' - adding the S where it was missing seems to have fixed the upload issues.
-
-
I'm having the same issue on a client's website, however the issue is only on their office computers and not anywhere else.
I was able to login through TeamViewer and replicate the issue and then immediately tried on my PC (same version of firefox as the client) and I didn't have the problem.
Any suggestions?-
Have you read through the comments on this thread?
-
-
-
-
-
Opened up a ticket with the client's host on their VPS, waiting on a reply back to see if they'll fix the PHP session.
Thanks, -
-
Yes, I updated the addon and the file browser doesn't even show up as an option. I check everything above. Still no luck..
Marta-
Hi Marta,
If the “Browse Server” button isn’t even showing up, it’s because you haven’t specified an upload directory yet. Go to Modules > Wygwam > [Config Name], and set that “Upload Directory” setting. -
-
-
-
-
I’m
solved!
I'm sorry, Brandon...
I overlooked it;)) after reinstallation.
Thanks again;)))
Marta -
-
Ok guys I'm also trying to fix this issue.
My setup is as follows:
The site is found like so: http://www.domain.com
But, the CP is found at: http://manage.domain.com
My URL to your "themes" folder reads like this http://www.domain.com/themes/
Brandon, I did your earlier test, inserting this into a php file:
The test passed.
I am really stuck on this one, any ideas?
Cheers,
Phil -
-
I’m
lost
Hi Brandon,
I am having this problem as well. I was able to work with my host to get the PHP scripts described above to return "pass"; however, I'm still getting the same "File browser is disabled for security reasons" message when trying to upload or use the file browser with Wygwam.
I'm using EE 1.6.8, Wygwam 2.1.3, FieldFrame 1.4.3. and nGen File Field 1.0.1.
The permissions on the session directory are set to 755.
I have a 301 redirect to force the www.
The paths in my Fieldframe settings are correct and use relative paths.
The paths to the Themes folder General Configuration is correct and uses a relative path, and the theme folder URL has www.
Paths and persmissions to all upload directories are correct.
I have set Control Panel Session Type and User Session Type to "Cookies Only".
Both my client (Member Group) and myself (Super Admin) are getting the same error message.
Putting a php.ini file with....
upload_max_filesize = 10M
post_max_size = 20M
max_input_time = 240
memory_limit = 250M
session.save_path = /tmp
....into /themes/wygwam/lib/ckfinder/core/connector/php (as well as the root and all the upload directories) made your 2-step testing scripts pass rather than fail, but didn't ultimately solve the problem.
The upload function worked fine 2 months ago, but my client has just noticed this problem recently. The host claims there were no upgrades or other changes to the server.
Any ideas? -
-
I’m
frustrated
I have a client reporting the same problem happening out of the blue, where everything was working correctly before - she just started getting the "file browser is disabled for security reasons" message. Same as last post, I've checked file paths, have "cookies only" set, etc. Have to get this fixed, they use this function often!
-
-
Brandon,
Same as Karen - upload worked great during development, but now can't upload images. both myself and the client can't upload. -
-
Sean / Karen,
Where have you setup your control panel. I previously had this problem because I had set the control panel up to run from a sub domain. I managed to fix the problem by moving the control panel access to mydomain.com/dashboard
Also make sure your theme folder paths are set correctly.
Phil -
-
Philip,
this just a basic install with the system folder on the same domain. -
-
And what have you set the path to your themes folder as?
-
-
/path/to/username/public_html/themes/
-
-
That's strange because that seems ok. Mine reads as follows:
URL to your "themes" folder: http://mydomain.com/themes/
Theme Folder Path: /var/www/vhosts/mydomain.com/httpdocs/pub/themes
I don't have the trailing '/' that may be worth a try.
Also, how do you access the site, are you accessing it with or without the 'www'
This will need to be the same in your URL to your "themes" folder. -
-
Sean, are you running 1.6+ and using ngen file field? I upgraded ngen file field and the problem was fixed - hope that will be the case for you, too!
-
-
Philip,
I removed the trailing slash and no go also there is no WWW in url to access the CP or in the way we access the site.
The site is on EE 2.1.1 Build: 20101020 and wygwam is version 2.1.4 -
-
Hi Sean,
Your EE & Wygwam versions are exactly the same as mine so there must be something we're missing.
I'm not sure what else to suggest without having a look at your setup. -
-
Hey guys,
I just posted a Troubleshooting page to the Wygwam docs: http://pixelandtonic.com/wygwam/docs/...
If you’re still having this issue, please read the last section on that page very carefully. -
-
Brandon,
thanks for the troubleshooting docs - it's the new host not remembering sessions and have now contacted them about fixing that. -
-
I'm getting this issue again. We're accessing the site through www. The themes directory is www. The directories are 777. The session_test on the troubleshooting page passes. The upload directories URLs are all relative. I'm using Wygwam 2.2.2 on EE 1.6.8.
-
The upload directories URLs are all relative.
Including the Server Path setting? That needs to be absolute. -
-
-
-
-
See attached picture. The server path is relative, but I use this setup on every site and it's not typically an issue for Wygwam.
-
-
I’m
happy
Another thing to check is the "Allowed File Types" in your upload directory settings in EE. If the "Browse Server" button shows for images but not files, then you most likely have the allowed file types set to "Images Only".
Trivial, but could be overlooked. -
