I have activated the Advanced Url Provider and a 404 error page in DNN 7.4.2. Works so far.
But: I deleted a page (also from the recycle bin) from the third level, let's say the Url was http://www.example.org/Level1/Level2/deletedPage - When I enter that Url now, I would expect that the 404 error page is displayed (as it is when I enter http://www.example.org/xxx/yyy/zzz) - but no, the parent page is displayed (http://www.example.org/Level1/Level2), with the Url of the deleted page, and in the IIS log file I find a http response status 200.
Any ideas?
Happy DNNing!
Michael
I would think when you delete a page, an custom Urls for that page would get deleted, but check the TabUrls table to see if there is an entry for /Level1/Level2/deletedPage in there.
The answer is simple. DNN takes the rest of the Url as query string parameters which could be used by a module, and the page does not "know" if that is needed or not.
In this example: As no page is available under
http://www.example.org/Level1/Level2/deletedPage
but a page is there under
http://www.example.org/Level1/Level2
it could be that a module needs or reacts to the querystring
?deletedPage
which is displayed as
http://www.example.org/Level1/Level2/deletedPage
by the Url provider. Therfore the behaviour is correct. An explanation can be found here, chapter "DNN pages & 404s" at the end of page 1 and beginning of page 2.
I've been using the Facebook Debugger to consistently solve a problem with og:image tags that we are using on an AngularJS site. My content editor has to clear caches in FB several times before getting the correct meta to come through. Here is our setup:
We are using a PhantomJS, disk cache enabled look aside for all UA ~ Facebook to properly pass FB requests to our static HTML markup. We have verified (via curl 'http://localhost:9000/path/to/my/page' | grep og:image) that the proper og:image tag is present before trying to share or present a new object to the FB Open Graph
We have to consistently "Fetch new scrape information" 3 - 4 times before FB Debugger pulls the proper image. The debugger returns scrapes in the following way:
-- First fetch: Default og tags before Angular bindings hit.
It's hard to say why this is happening since we haven't tried to share the page previously. We've passed the page into the PhantomJS process and seen the proper og in the returns (in order to cache the return before sharing or heading to FB).
-- Second fetch: Proper og tags filled in with desired image but with the OG Image warning
og:image was not defined, could not be downloaded or was not big enough. Please define a chosen image using the og:image metatag, and use an image that's at least 200x200px and is accessible from Facebook. Image 'XXXXXXX' will be used instead. Consult http://developers.facebook.com/docs/sharing/webmasters/crawler for more troubleshooting tips.
The desired image is 600x337 png (no transparency) so size isn't an issue (and it eventually shows). The fallback image being used instead is the default og:image previous from scrape #1.
-- Third fetch:
OG Image warning is gone and all additional fetches return the proper meta. Sharing works and we can move on.
So while this works, it is a little heavy handed. Clearly we have an issue with FB seeing our default meta, caching that meta, and needing us to clear things out. Before we implement any cache warming in out PhantomJS process, and possibly a POST to the FB API to get the proper scrape markup into Open Graph, can someone answer why the additional 2nd refresh produces the og:image warning and then it goes away? If the proper og:image exists and is correctly sized, why the error?
We looked at this answer, and the comment says to clear our browser cache when using the debugger. We've considered the comment to use multiple browsers but to no avail. We've tried cache-less POSTs using Postman to test this theory as it may be how we cache warm but still see the need for the additional refreshes.
Is there a way to increase the results of the Content Sources displayed.
For now only 5 Content Sources could be viewed at a time. We have 1300 means 277 pages. To find a Crawler I have to navigate the damn slow 277 pages. Me and my team is banging head hard to find a solution. We tried to find something in SearchAdmin.war, nothing relevant is found in that also. There should be an option to increase the number of Content Sources in a collection to be viewed. Like 100, 50. Or whatever. Please if someone know out there HELP!!!
In case anyone faces the same problem. They can follow these steps.
Working on Portal 8. Please take relevant backups before doing anything in production :)
-> /IBM/WebSphere/PortalServer/search/wp.search.admin/installableApps
-> Copy to local SearchAdmin.war
-> Extract SearchAdmin.war
-> Edit SearchAdmin\jsp\html\ManageContentProviders.jsp
-> go to this line (rowsPerPage="5") < Change 5 to what ever value you want.
-> Login to portal console
-> Navigate to WebModules
-> Search for SearchAdmin and update with the modified .war
Restart not required. :)
I have a dnn 7.1.1 installation I am testing for production. I thought that this version supported a 404 error page. But no matter what type of erroneous url I pass to the DNN site I don't get this page appearing and I don't see it under admin/page management. DO I have to turn this feature on some where? This is a brand new install and the following page says it should be turned on by default: DNN 404 wiki
I could not find any setting in the root web.config. The advanced url provider is enabled.
Can someone help me figure out how to timplement this 404 error page
Thanks in advance
EDIT 1:
Can someone confirm that 7.1.1 is the minimum version for this feature, or is it only with the professional version, I am using DNN platform.
EDIT 2:
See HERE for link to DNN issue tracker. I have tried this both with a new installation and an upgrade from 7.0.6 and the problem continues. If you ask for an non-existent resource with an extension you get a generic asp server error:
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its
dependencies) could have been removed, had its name changed, or is
temporarily unavailable. Please review the following URL and make
sure that it is spelled correctly.
Requested URL: /blob.aspx
if you request a page wihtout an extension like /blob you get one of two errors:
404 Not Found
The requested Url does not return any valid content.
Administrators
Change this message by configuring a specific 404 Error Page or Url for this website.
OR
The resource you are looking for has been removed, had its name
changed, or is temporarily unavailable.
There is no 404error page in the admin/page management section of the site in either the upgrade or brand new instal. The new instal was deployed uwing Azure website Gallery for DNN 7.1.1.
I manually upgraded a 7.0.6 instance to 7.1.1 to get the other testing environment.
EDIT 3:
Okay, so I know how to reproduce this. If you create a new portal/site with the blank template then there is no 404 error page under admin/page management. If you create a site with the default English template then the 404 error page is listed in page management and the 404 page shows up when you request a deadpage.
WHat I tried:
I copied the 404 error page from the default template site into the blank template site hoping that this would fix the problem. It did not. So now I think that there is a setting that needs to be enabled somewhere, but I know it is not in the web.config file because both these portals are in the same dnn instance and one works and the other does not, so there is another place I have to find this.
EDIT 4:
I don't have a work around other than creating new site with default template and recreating a site. It appears that this error is planned to be fixed by 7.2.1 as documented HERE
EDIT 5:
I dug through the databse to see if I could find a setting that would make this work. The only setting I could find was in portal settings (called 'AUM_ErrorPage404'), so I duplicated it with the following script but changed the portal and tabID to match the portal that was created with the blank template .
This added a setting to portal settings that assigned a error page to the portal. I found this setting for the default template and not the blank template. SO I added it hoping it would solve my problem. It did not.
INSERT INTO [dbo].[PortalSettings](
[PortalID]
,[SettingName]
,[SettingValue]
,[CreatedByUserID]
,[CreatedOnDate]
,[LastModifiedByUserID]
,[LastModifiedOnDate]
,[CultureCode])
VALUES (
[PortalID]
,'AUM_ErrorPage404'
,[TabID of 404 Page I Created]
,[CreatedByUserID]
,getdate()
,[CreatedByUserID]
,getdate()
,'en-us')
I found no settings for the 404error page/tab in the [TabSettings] for the page created in the default template, in fact, there were no records in tabSettings for the error page created in the default template portal..
A brand new site created with the default template in 7.1 only has the following portal settings (with values):
AUM_ErrorPage404 371
DefaultAdminContainer [G]Containers/Gravity/Title_h2.ascx
DefaultAdminSkin [G]Skins/Gravity/2-Col.ascx
DefaultPortalAlias test404
DefaultPortalContainer [G]Containers/Gravity/Title_h2.ascx
DefaultPortalSkin [G]Skins/Gravity/2-Col.ascx
EnableSkinWidgets True
GettingStartedPageShown True
GettingStartedTabId 346
MaximumVersionHistory 5
PortalAliasMapping CANONICALURL
SearchAdminInitialization true
TimeZone Pacific Standard Time
I am not sure where else to look in the DB for a setting to chnage
After some research and hours of frustration. I found that a new setting is required in version 7.2.2:
The table: PortalLocalization now contain two fields: Custom404TabId and Custom500TabId, those fields need to be updated with the same value of the PortalSetting AUM_ErrorPage404, AUM_ErrorPage500 so if you upgrade from a version below to 7.1 probably you have to update those fields by yourself.
Hope this save time.
Israel Garcia
Okay, I got it to work!
The script above did the trick:
INSERT INTO [dbo].[PortalSettings](
[PortalID]
,[SettingName]
,[SettingValue]
,[CreatedByUserID]
,[CreatedOnDate]
,[LastModifiedByUserID]
,[LastModifiedOnDate]
,[CultureCode])
VALUES (
[PortalID]
,'AUM_ErrorPage404'
,[TabID of 404 Page I Created]
,-1
,getdate()
,-1
,getdate()
,'en-us')
The missed step:
After adding the setting for AUM_ErrorPage404 I had to clear the cache and restart the application. Now it works.
Google Webmaster Tools is giving me loads of crawl Errors of a certain type but I just can't see where its getting it from
Its reporting that the error is a 404 on this page (which definitely doesn't exist)
http://www.soundshelter.net/artist/www.soundshelter.net/artist/Arnold+Jarvis
and its being linked to from this page
http://www.soundshelter.net/artist/Arnold+Jarvis
There is no link to the first page anywhere on that second page. I am getting the same error for so many of the pages on my site (all dynamically created)
Any ideas why this is happening? Could it be something to do with the way I'm creating links in the code?
Arnold Jarvis
Cheers!
Hay Franco the problem is in your canonical code in your website thats create all the 404 errors.
For example take this page
http://www.soundshelter.net/artist/Arnold+Jarvis
on line 33 you will see this line
<link rel="canonical" href="www.soundshelter.net/artist/Arnold+Jarvis" />
This line create the 404 page across all of your CMS system its probably some of the system addons if you will add there http:// all of your 404 pages will be fixed:)