This is puzzling me a bit.

I have a RadEditor on my page and it has the Image Manager as one of the tool bar options. During development & testing locally the Image Manager works as expected. However, after I upload my site to my host provider, when I launch the Image Manager, instead of getting what one would normally expect, it opens up a window with the site's home page instead. All the other buttons on the toolbar appear to function as designed. It's just with this particular one.

Has anyone encountered this before?

Thanks...

Signed,
Confused

Hello Paul,

Most likely your hosting provider has configured its server to redirect to the default page when a server error of some kind occurs, so as to avoid the users seeing the .NET server exception.

This is the only explanation that makes sense to us with the information provided. My suggestion is to contact your provider and ask them to examine their logs, and inform you whether such a server exception indeed occurs when you open the ImageManager, as well as what its message is.


Sincerely yours,
Tervel
the Telerik team

My thought is it may be a permissions issue, but giving the folder write access didn't help. My host provider is GoDaddy, by the way.

I also tried the default toolbar and all the other "Manager" buttons exhibit the same behaviour.

I even tried allowing only viewing capabilities and removed uploading, but that didn't help either.

I contacted their support as well, but we'll see how far that goes. I'd hate to have to switch hosting services just to allow file uploads... I mean really... isn't that a common task most web hosting companies would expect websites to allow?

What are the "managers" doing behind the scenes when someone clicks on it? I tried setting it so I can view only - no uploading or deleting. It still redirects to the home page. I tried it without anything but the default parameter settings with the same results.

I can't possibly be the only person using this control with GoDaddy (although anything is possible).

I've seen a few threads (in relation to GoDaddy) which showed similar issues, but they reported getting an error. I tried those solutions as well just to see if it would help and it had not.

If it is an issue with my hosting service, is there any other web hosts out there that are 100% compatible with your product? My hosting services are due to be renewed soon and if I have to move my site, I may as well do it now (although I'd just as soon like having the issue resolved without having to)

I've discovered the cause of this strange behaviour. It is not the control itself, but my host provider GoDaddy. I'm currently working with them (though they are a tad slow to respond) on a resolution (hopefully).

Here is my setup and discovery in case anyone else experiences the same issue:

My hosting plan with GoDaddy allows me to have alias domains. My alias domains all reside in their own sub-folder off of the root folder. Respectively, they each have their own virtual directory setup in the IIS settings.

If I upload a page with the control to my primary domain which resides off the root, the control works as designed. If, however, I post it to one of my alias folders, the control breaks (at least as far as any of the managers toolbar options are concerned) and redirects to the home page instead of loading the manager.

This leads me to believe that GoDaddy needs to adjust settings in order to allow my alias domains to behave like my primary domain. We will see where that leads us. Otherwise the only solution is to get individual hosting setups for all my alias domains, essentially defeating the purpose of having them in the first place.

Hopefully I'll be able to post a resolution soon.... <sigh>

This is the response I got from GoDaddy:

You are going to want to review your script as the files are most likely calling a file that cannot be found by using MyDomainName.com as the script may be looking for the file in the root directory but maybe the incorrect root directory. 
Unfortunately, we do not provide technical support with third-party scripting issues. We are very limited in the support we can offer for customer-written code or scripts. If there is evidence that our system is responsible for the error, please forward it to us, and we would be happy to look into the matter further. But at the moment this does not appear to be the case, so we regret we can not assist you further with this issue.

If it couldn't find the correct script directory, wouldn't it make sense that the rest of the control would be broken as well?

I did notice this when I clicked the image manager icon on both the working & non-working locations -

Running it off the root loads this URL:
(I removed some parameters to keep the sample small)
http://mydomain.com/Telerik.Web.UI.DialogHandler.aspx?DialogName=ImageManager&Skin=Default&Title=Image+Manager&doid=4d38813f-29ff-46dc-867d-924beb76af32&dpptn=&dp=blahblahblah....

However if it's run from an alias it loads this URL:
http://mydomain.com/#

It does appear that it doesn't look like it knows where to locate the Telerik.Web.UI.DialogHandler.aspx script when it's run from the alias domain or even attempt to know it even exists.

Comparing the source from both pages these are the only differences:
(by Application Path for my Alias domain is aeon)

Working: (/Root)

<script src="/WebResource.axd?d=GevukDGZVxFfGP5TzijJUA2&amp;t=633440804590133643" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=JkffN9NsczSK3hdb39CDDwhDxj8uQ4m5rL-FdxtMqEAPHxw0FxETX73AB7FT-yLi4zc717KO926WIQUwmDnYjNCPGIhdOBey_uW1AMuAlIY1&amp;t=633082630123362548" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=JkffN9NsczSK3hdb39CDDwhDxj8uQ4m5rL-FdxtMqEAPHxw0FxETX73AB7FT-yLi4zc717KO926WIQUwmDnYjGVAywog3Aa4lPZP-ivH3m81&amp;t=633082630123362548" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtllEZyDNyfFciihUYRIePmCpURgidy0gCEQCy_B2JJXDBGS94VYLvWD6LrcnZZa43pQ2&amp;t=633565860267386079" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtlpZgiws-AId0XBvla3ytwWyemFJTFcdloT3NwgsbOprV0&amp;t=633565860267386079" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtlpZgiws-AId0XBvla3ytwWzyWwyXM0ZeSz_-vjK25uRaGJboPAIxuMdZsWsWbPUw8Q2&amp;t=633565860267386079" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtltwK3Lc-_u5JBukS-7VlGENf6CktDAH8_lUGepK2EvzHJb_XgeXv-W_2jKeKAIXvYg2&amp;t=633565860267386079" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtlrjvC0OEwQN5Z0C6X_wrskzwTeI8bIyHjEb7bEgxDIfqacaJZBpS1jBzk3dKSftjNQ2&amp;t=633565860267386079" type="text/javascript"></script>

<script src="/ScriptResource.axd?d=cD2mrv1WJqcPXubC_KxtltwjnBLTKIgElp5OxRdkB-esRcopG-PHIasXWN_a2mUfGJQrWT9_cB4iSgX95EUWtA2&amp;t=633565860267386079" type="text/javascript"></script>

<script type="text/javascript">

Non-Working (Alias Hosted - /Root/aeon):

<script src="/aeon/WebResource.axd?d=Uvd1TE7ugiqh-Ea84-Wy7Q2&amp;t=633440804590133643" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=-JRNKxntMhWdC1IKCmMftRumke8wegAGDtR3H-nMgunieS5sla8AzgfoCE2tE6rBnhDNoXoeuzKGe0x__tvYDWPrQvfeH1PjZWLuU6ALy-Y1&amp;t=633082630123362548" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=-JRNKxntMhWdC1IKCmMftRumke8wegAGDtR3H-nMgunieS5sla8AzgfoCE2tE6rBnhDNoXoeuzKGe0x__tvYDY7fcvEYFlu0GQYLWS3FuaA1&amp;t=633082630123362548" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xkBfSUz9P_S3yJiYedQQtjhlON5Zlg6LjXVDKSoLzW7MceBLZ9qe4G_XdJFEk-iiew2&amp;t=633566278085882499" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xgZP330P_ChiJ1EXwwXodMloHfsZLkhfqOohVHF75HtM0&amp;t=633566278085882499" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xgZP330P_ChiJ1EXwwXodMmjbSfylgKIJ2pX7qM1vPXV7tlYMvYo0AB4g9ttTXzy7w2&amp;t=633566278085882499" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xmt8m6FCkx_RadErejyzcv3TjULWGU43-BX9dwk4o4tEcJ-VW_dkvQ76RuviGtbKqg2&amp;t=633566278085882499" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xk80qYLUfsR2iKfoKKC1CjJ0zH0N2MhYVsjK5BT2V0SnQjUJN3yqFyMhLhEvMu2yMw2&amp;t=633566278085882499" type="text/javascript"></script>

<script src="/aeon/ScriptResource.axd?d=WlfzMjgrbLCFvb8kfld_xoUTuRsFQDlayWjHlzfyBGSu7XIoss-uCKsuG1pwvDt1e7fUC9WYiTTc_sQMLRhHSw2&amp;t=633566278085882499" type="text/javascript"></script>

<script type="text/javascript">

I've tried various other tests, but nothing works. I'm not really sure who's issue it really is, but if you can provide ammo to go back to GoDaddy with I would appreciate it.

Thanks!

Hello Paul,

I have read this thread from the start and I have a few suggestions for you to try.

First, install a HTTP debugging proxy (Fiddler for IE or Firebug for Firefox) and check what happens with the Telerik.Web.UI.DialogHandler.aspx request. By default, the editor is configured to make a request for the Telerik.Web.UI.DialogHandler.aspx file in the same folder as the web form, where the editor is. For example, let's assume you have a page http://myserver/application/folder/WebForm.aspx which has a RadEditor control. If you open a dialog, the editor will make a request for http://myserver/application/folder/Telerik.Web.UI.DialogHandler.aspx. If possible, open a formal support ticket and send us the site URL and details on how to reach the editor control, so we can test the behavior from here.

This dialog request is handled by the httpHandler entry you have in the web application's Web.config file. If there is a different handler or HTTP module, which is placed before our own dialog handler, it might alter the request - e.g. redirect it to the home page. Also, see if there is a second Web.config file in your application, which clears the HTTP handlers. If this is the case, then the request for the dialog handler will cause a 404 not found error.

If nothing else works, you can try overriding the default editor behavior and creating your own dialog handler file. Here is how to do that:
1. Set the editor's DialogHandlerUrl property to "~/Telerik.Web.UI.DialogHandler.aspx".
2. Create a new file called Telerik.Web.UI.DialogHandler.aspx in the root of your web application
3. Put the following line in the newly created file:
<%@ Page Language="C#" Inherits="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" %>

Next time you try to open a dialog from the editor, it will look specifically for the Telerik.Web.UI.DialogHandler.aspx file in the application root folder and the Web.config httpHandlers entry will have no effect.

In summary, here are the three suggestions I gave you:
1. Use Fiddler to check what happens with the Telerik.Web.UI.DialogHandler.aspx request.
2. Check your web.config files /ask GoDaddy/ for any 3rd party http modules that could interfere with the request.
3. Try creating a physical dialog handler file in your application

Sincerely yours,
Lini
the Telerik team

Hi Lini,

Thanks for the suggestions. I will work on them and see what I find out.

I was actually able to screen capture what happened when I clicked on the image manager button for each of the domains and they both looked the same:

Waiting for http://bothmydomains.com/Telerik.Web.UI.DialogHandler.aspx?DialogName=ImageManager&Skin..... etc etc...

This is why I found it confusing, it appeared to behave like it would work.

I'll go through your suggestions and if I can't get them to work I'll open up a support ticket.

Thanks!

Hi Lini,

Thanks for the suggestions. I will work on them and see what I find out.

I was actually able to screen capture what happened when I clicked on the image manager button for each of the domains and they both looked the same:

Waiting for http://bothmydomains.com/Telerik.Web.UI.DialogHandler.aspx?DialogName=ImageManager&Skin..... etc etc...

This is why I found it confusing, it appeared to behave like it would work.

I'll go through your suggestions and if I can't get them to work I'll open up a support ticket.

Thanks!

did this ever get resolved....
I am having lots of issues with IO permissions in a GoDaddy hosting environment.
Thanks
Clint

Hello Clint,

I think the original poster was forced to change their hosting provider because they were not able to provide any explanation for the problematic behavior.

You seem to be experiencing a different issue - IO permissions mean that the ASP.NET account used by RadEditor cannot read/write files in your account space. If you are using the editor default configuration and your site is set to Medium trust or higher, you should not experience any IO related security exceptions. Please open a support ticket with GoDaddy and ask them about the permissions errors and if they apply any extra security restrictions on your account and the application pool user, which is used by the ASP.NET pages to access the files.

All the best,
Lini
the Telerik team

Hi there! I am using DNN on GODADDY, yes, and I'm having problems with the image editor paths.

I have two entirely separate installations, one for development and one for production.

Go Daddy doesn't let you install DNN at the root, so I'm using hosting aliases in ONE hosting account.

root/production (for the production site)
root/development (for the development site)

So, in the default DNN configs, I can change the absolute path to the relative, but it doesn't default to /portals/0/ as the root; it still has
/production/portals/0/ and
/development/portals/0

If I back up a development site to production, all the links are grabbing images from the development site, and I want them to be grabbed from the actual production site.

Is there any way around this besides having two entirely separate hosting accounts with the same tree structure in both?

I "think" that this piece of advice to another poster might point in the right direction, but there might be a simpler way for it to default to
/portals/0/ ?

--------------------------------------

If nothing else works, you can try overriding the default editor behavior and creating your own dialog handler file. Here is how to do that:
1. Set the editor's DialogHandlerUrl property to "~/Telerik.Web.UI.DialogHandler.aspx".
2. Create a new file called Telerik.Web.UI.DialogHandler.aspx in the root of your web application
3. Put the following line in the newly created file:
<%@ Page Language="C#" Inherits="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" %>
----------------------------------------------------

Thank you so much!