This is a migrated thread and some comments may be shown as answers.

ImageManager strange behavior.

11 Answers 157 Views

Editor

This is a migrated thread and some comments may be shown as answers.

11 Answers, 1 is accepted

answered on 09 Sep 2008, 06:30 PM

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)

answered on 10 Sep 2008, 01:17 PM

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>

answered on 10 Sep 2008, 03:28 PM

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!

answered on 11 Sep 2008, 12:19 PM

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

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

answered on 30 May 2009, 10:00 AM

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

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

answered on 07 Jun 2013, 04:14 PM

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!