If you haven’t subscribed to our free podcast yet (you should!), then you might have missed episode 27, which was released yesterday.
@dan and I discuss what you need to do before getting your first RapidWeaver site online. We also let you know about four new exciting addons this week and rant about web design trends.
Was a lot of fun just chatting about RapidWeaver and the Community! I really appreciate you having me on the podcast. Look forward to doing it again sometime in the future!
Thanks for answering my Q on the podcast. I must say that I am guilty of the preloader use. I tried it first just out of my childish “ooh, fancy spinny thing!” curiosity. I’ve since found actual practical applications for it though. For example, I am drafting up a site that has a large’ish header image (large in dimension, not really in file size), and it has a logo and title overlay. Everything loads briefly before the header image so it has this jumbled appearance before the image loads and properly spaces things out. Just seems like a distracting first impression for a user.
Admittedly, there are probably ways to fix that spacing issue that I just am unaware of so I still may be using the preloader unecessarily, but that’s the practical application for me.
Easiest is to set the header container height to the same as the image height, and choose a default background colour that best matches the image being used.
This way the header area is the correct height, and it has a background colour that kinda matches the image being loaded.
Do that and you shouldn’t see the “jumbled appearance”
As a side note: I still don’t think that your reason for using the loading screen is better than actually getting some content in front of the user — I always say you should get some content in front of the user ASAP, so he/she knows that the page is loading and gets some visual feedback.
Hi there,
i’ve listened to your podcast. It is interesting. I like the shorter shows more then the long ones.
I have some comments on episode 26. You are telling to add a custom 404 page to a website. This is a good idea. But the way you suggest to add it is not completely correct. You tell to add it in the project and use any plugin you like to create the 404 page. But if you do it like that, the http header will sent the code 200: page found.
That’s a bad thing. Because a 404 error is used by search engines to delete pages from their index. That way, their index becomes more accurate, more up to date and they are able to give better ‘answers’ the next time for the same request.
So, in addition to what you’ve said in the podcast, you should tell your page to sent the correct http header. That is done easily in Rapidweaver too:
name the page 404
choose .php as the file type
go to the third tab on the page inspector
Choose : ‘Prefix’
add the following code:
<?php header("HTTP/1.0 404 Not Found"); ?>
publish
The step of calling the error-document in the .htaccess will stay the same.
So, just saying that a page is a 404 page, doesn’t mean it is a 404 page. Or, how Google likes to phrase it:
It’s like a giraffe wearing a name tag that says “dog.” Just because it says it’s a dog, doesn’t mean it’s actually a dog.
I posted about this in another thread. But briefly :
You have RW in it’s default setting of “Links relative to page”.
When you visit the rubbish url and the 404 triggers, then the 404 page is served from this rubbish location, and links are relative to that page, as seen in a screen grab from your site below:
If you se this workaround you should probable stop search engines indexing the 404 page as well by including this meta tag in the head of the 404 page : <meta name="robots" content="noindex">
I changed my File Links are setting to: Relative to DOCROOT and published the site after checking each page for errors in the them and stacks. All looked OK
I then ddded your extra code in my htaccess file (See screen shot) but still have the same issue
Not sure what’s going on there. Just had another look round your site, and all the links still look relative to the pages.
Edit: Just been testing this myself. I’m not sure it’s even possible to get the links to the stacks css and stacks javascript files to resolve correctly by any means, in this situation.
I personally went with my 300 redirect option I pointed at.
This simply redirects the page to the 404 page just as if it were any other page if it finds the requested url is non existent, instead of serving a real 404 error it treats it as a 300 error.
The user is non the wiser.