In the sitemap I have arranged that a neat 404 page is shown for non-existing pages. This neat page is not shown when I access a non-existing url in the static folder. How can I achieve this?
On the top level in your sitemap you need to add an any matcher that points to the 404 page.
see also:
https://documentation.bloomreach.com/14/library/concepts/error-pages-and-error-handling/2.-add-a-catch-all-sitemap-item-that-creates-a-dynamic-404-page.html
Related
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 am setting up a simple app to save links of interesting articles. I'd like to be able to retrieve the description of the meta tag from the website of the URL or at least the first headline or text that appears in the page that is accessed when accessing that URL, to display this next to the URL:
This is the app so far:
http://ux.machinas.com/mux-feed/
Is there a way to do this in angular?
I am facing a similar problem. I am getting a cross-browser script error when trying to get page info with $http.get(), ie $http.get('http://www.stackoverflow.com').
I think the best solution is to get the page info on the server, then send to the browser, ie.
$http.get('./api/getPageInfo.php?url=www.myUrl.com/whatever').then....
this thread explains how to get page info in PHP - Get Facebook meta tags with PHP
I would like to point a site to an index.html page to get it started, but don't want to include index.html in my search results- instead just having the child pages appear in the results. Is there a away to remove specific pages?
Just as an update, the only solution I found to my problem, was to remove those URLs from the collection after is was crawled as a secondary step.
i am having a strange issue. I am seeing a lot of people visiting my 404 page of the website. but i am not able to track from where are they being referred to the 404 page.
the website has been made on cakephp framework.
in the page controller code when the page object is null we are redirecting it to the 404 page.
We are not able to find the referrence url from where the 404 page i being loaded.
the analytics gives keywords and landing pages. but we have checked all of them and none of them are going to 404
can anyone help.
www.vresorts.in
If you'd like to know the referrer, you can use $this->referer()
We've recently launched a large website for a client, and have put in place the 301 redirects for all the links on the site.
Looking at the logs, there are a lot of 404 for images. How is best to handle image 404 errors? Are we best redirecting requests for images in the old link structure to the home page?
Thanks in advance for advice on this.
One possible solution, would be to make a small-ish image that simply says "404" or "Image not available". Since the browser is expecting some sort of image to display, this would be a better solution than returning some "404" text, which is just going to display as a broken image in the rendered page.