DNN 5.6
AF 4.3.2
Not using AS

I configured Vanity URL's as per the instructions and they worked great.. only trouble is all png images are now gone from my site!

I tracked this down to this :
 

Removing the attribute seems to resolve the images problem but then then vanity url's don't work.

The vanity urls work great BTW.. and very nice feature.. but I need the images more than vanity url's.

We have had several customers using 5.6 throughout the beta period. There are some issues with 5.6, but I haven't seen the problem with PNG's not appearing. I just tested 5.6 again to make sure PNG's load, and they do. However, 5.6 will automatically add all the PNG entries to your portal alias table. There is also a workaround that needs to be applied in 5.6 in order to continue to access the root of your site with vanity urls enabled. Details are available in the following KB article.
http://www.activemodules.com/active...nity-urls/

Found something :

http://local.dotnetnuke.com/Resourc...fault.aspx

Second post in the above thread (to which you later posted).

Strongly recommend following Will's guidance.

I would also encourage you to look at http://www.activemodules.com/active...der-iis-7/ - even though it's for ActiveSocial.

Will does know what he's talking about on this.

I have follwed the guides to the letter.. it just doesn't work. I have also tried everything on the page you linked to, and tried disabling all other modules.

Unfortunately runAllManagedModulesForAllRequests="true" causes png images not to be sent to the browser.. it's a bug in DNN 5.6.0 as far as I can tell.

I just had a look at the source code on codeplex.. there's been some checkin's recently for the URLRewrite module which is where the issue seems come from. I downloaded and built from the source and it did resolve the png issue, with the vanity url's working fine, however it broke downloads from our website . This is what I see now :

-------------------------------------------
DotNetNuke Error

Domain Name Windows Vista Does Not Exist In The Database

DotNetNuke supports multiple portals from a single database/codebase. It accomplishes this by converting the URL of the client browser Request to a valid PortalID in the Portals database table. The following steps describe the process:

   1. Web Server Processing
          * When a web server receives a Request from a client browser, it compares the file name extension on the target URL resource to its Application Extension Mappings defined in IIS.
          * Based on the corresponding match, IIS then sends the Request to the defined Executable Path ( aspnet_asapi.dll in the case of ASP.NET Requests ).
          * The aspnet_isapi.dll engine processes the Request in an ordered series of events beginning with Application_BeginRequest.


   2. HttpModule.URLRewrite OnBeginRequest ( UrlRewriteModule.vb )
          * The Request URL is parsed based on the "/" character
          * A Domain Name is constructed using each of the relevant parsed URL segments.

            Examples:

            URL: http://www.domain.com/default.aspx = Domain Name: www.domain.com
            URL: http://209.75.24.131/default.aspx = Domain Name: 209.75.24.131
            URL: http://localhost/DotNetNuke/default.aspx" target="_blank" rel="nofollow">http://localhost/DotNetNuke/default.aspx = Domain Name: localhost/DotNetNuke
            URL: http://www.domain.com/virtualdirect...fault.aspx = Domain Name: www.domain.com/virtualdirectory
            URL: http://www.domain.com/directory/default.aspx = Domain Name: www.domain.com/directory

          * Using the Domain Name, the application queries the database ( Portals table - PortalAlias field ) to locate a matching record.

            Note: If there are multiple URLs which correspond to the same portal then the PortalAlias field must contain each valid Domain Name in a comma seperated list.

            Example:

            URL: http://localhost/DotNetNuke/default.aspx" target="_blank" rel="nofollow">http://localhost/DotNetNuke/default.aspx
            URL: http://MACHINENAME/DotNetNuke/default.aspx
            URL: http://209.32.134.65/DotNetNuke/default.aspx
            PortalAlias: localhost/DotNetNuke,MACHINENAME/DotNetNuke,209.32.134.65/DotNetNuke

            Note: If you are installing the application to a remote server you must modify the PortalAlias field value for the default record in the Portals table according to the rules defined above.
----------------------------------------------------------------------------------------
that was when attempting to download a file from a virtual directory e.g :

http://www.mydomain.com/downloads/product/700/dodah.exe

downloads is configured as a virtual directory in IIS7. It seems DNN5.6 is seriously broken.

There are 2 specific flaws in DNN 5.6 I'm aware of;

- the PNG issue, which I do not experience even though I use runManagedModulesForAllRequests
- an issue with Google Analytics which is resolved by using Oliver Hine's enhanced analytics module or modifying siteanalytics.config

Re the PNG issue, a possible workaround is to use iFinity's free Friendly URL Provider (http://www.ifinity.com.au/Products/...r_For_DNN) instead of the DNN standard one. I can't guarantee it, because I use the paid iFinity URL Master, and this appears to be the reason I don't encounter the issue (although I also use Snapsis Pageblaster).

I would suggest the Friendly URL Provider may be worth a try in your case, rather than building off latest source.

There is one other issue I'm aware of, which is Snapsis Pageblaster under DNN 5.6 removing the closing tag (>) of files. This is not a core issue, of course.

I wasn't aware of the Google Analytics issue, can you provide a reference to it?

We use Inventua HRefExchanger, however I have already tried removing it to confirm that is not the cause of any issues we've been seeing lately.

I recall that we did try pageblaster a while back however I think it conflicted with another module.. might even have been with hrefexchanger (will have to check with someone here to confirm that). I'd like to move away from using HRefExchanger (doen't seem to be in active development) but haven't found anything that works the same way.

No worries. http://www.dotnetnuke.com/tabid/795...fault.aspx

I have a very high opinion of iFinity's modules if that helps.

Vanity URLS are still not working for us with DNN5.6.1. - we have a virtual directory with a bunch of folders and exe files for downloading, when vanity urls are enabled I get 404 errors when attempting to download. It seems to still be an issue with modulesrunAllManagedModulesForAllRequests, I have disabled any other modules that I could find that might cause problems (Inventua HRefExchanger).

So has anyone else gotten Vanity URL's working and still has non dnn virtual directories working? I'd really like use this feature.

The problem is with the DNN URL rewriter. They are only handling certain extensions the throwing a 404 for the remaining extensions. I created an issue with DNN along with a recommended fix. Supposedly they will have it fixed in 5.6.2.

Ok thanks, I guess I'll have to wait for them to fix it.. there have been a few checkin's for the urlrewriter module since 5.6.1 but it doesn't look like those changes would fix the problem.