W3 Validation errors - validation

I am validating against html5 and I know that the validator is not 100% but it even shows it should allow this in it's suggestion...
Ouptut:
Line 75, Column 92: Bad value home for attribute rel on element a:
Keyword home is not registered.
…bomb/" rel="home" title="beefbomb.com"><img src="http://localhost/local_folder…
It then tells me to take a look at the microformats wiki... http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
Which defines:
Keyword: home
Effect on a, area: Hyperlink
Brief description: …indicates that the [referenced document] is
the homepage of the site in which the current page appears. can be
combined with 'alternate' to indicate for example a feed for the site
of the current page.
Link to specification: rel-home
Why could this be?

Microformats aren't part of the official spec. A future ua could come along that decides to treat links with rel="home" on them as links to go to the homescreen of the device for instance, without going against the spec.
The warning is to ask you, "Have you done this for a reason, or by mistake?". If you know what you are doing and why, it's fine. If you decided to make up a new rel attribute for your own reasons, you get told that it's not in spec, but that a system already exists that uses it.

Related

Markup tags in product descriptions

I'm trying to use markup tags to link to info pages within the "description" attribute of a product. However, it's not giving me a clean URL path when the description is printed to the page.
Trying:
Contact Us
does not give the expected url. I've confirmed i'm doing this outside of WYSIWYG mode too.
When the text is rendered is returned to the browser as this html:
Contact Us
A resulting click on the link then ends up as:
http://example.com/prod-category/my-product/%7B%7Bstore%20url=
From what I can tell the markup tags aren't designed to be used in this way. Is it possible to extend it so it could work? Otherwise I guess I need to include the actual URL in the description?
Thanks for suggestions.
You can´t use the double-curly syntax because the attributes value is not being processed by magento´s template filter, which does the magic. You can use them e.g. in CMS or email Templates out of the box.

Tumblr: how do I remove the description/sidebar box on the submit page in the default Peter Vidani theme?

I have a tumblr account that has submission enabled, and I have a short description with a form in the "description" area that appears on the sidebar. However, this description also appears on myblog.tumblr.com/submit. I'd like to remove it.
I looked at the documentation on http://www.tumblr.com/docs/en/custom_themes#navigation, but haven't been able to figure out how to prevent the sidebar description from showing at the top of the submit page.
Can anyone help?
I'm not sure if I understood your question correctly. But if I did, a work around would be using jQuery to check if the current url contains the string /submit and simply disable the sidebar, or the element that contains the description.
I don't know jQuery but I know it's possible. I'd suggest you to look into this post:
How to check if the URL contains a given string?
and combine it with this line (replace the "alert part")
$("#sidebardescription).hide();
Another solution would be if Tumblr provided you with a way to only render for specific pages. They usually do that. I'd look into this part {block:SubmissionsEnabled} {/block:SubmissionsEnabled} before I go with the workaround.

Remove default nonexistent footer links

I have a problem with my MediaWiki installation on a local network. I'm using MediaWiki in German. There are several footer links in my wiki, that throw a 404 error. For example in the footer there's a link Impressum (in English: Disclaimer). It points to *NameOfMyWiki*:Impressum which does not exist.
When I go to MediaWiki:Disclaimers, then a Disclaimer shows up, it's the page that should be behind *wgSitename*:Impressum. I don't think it's intended that I have to point the disclaimer link to MediaWiki:Disclaimers.
Another behaviour that probably is based on the same problem is, that a user gets a 404 on his own user page, when the user page is still empty/not already created (clicking on the link on the top right next to settings). When another user edits the user page of the first user, the first user then can access and edit it, too. But not when it's still empty/not defined.
How can I fix that?
The text of the footer links comes from the interface messages MediaWiki:Privacy, MediaWiki:Aboutsite and MediaWiki:Disclaimers. To disable one or more of these links, set the corresponding link text to a single hyphen (-).
Alternatively, since MediaWiki 1.17, you can also modify the footer by defining a hook in your LocalSettings.php.
Ps. For anyone interested in going to all the way to the source, the code that handles these links is in the Skin::footerLink() method. The practice of disabling various interface features by setting the corresponding message to - is actually pretty common (though not universal) in MediaWiki; completely blank messages are treated a bit weirdly for historical reasons, so - is commonly used as a stand-in for "no value".
Edit: I just noticed that you were also asking a second question about user pages. To answer that question better, let me start by describing how MediaWiki should be treating non-existent pages:
When MediaWiki sees a wikilink (most, though not necessarily all, links in the navigation menus are also handled the same way) pointing to a non-existent page, it creates what is known as a redlink. These links are styled differently from normal links (typically they're colored red, hence the name) and point to an URL that looks something like this one, with the parameters action=edit (making it a special kind of edit link) and redlink=1.
When a user clicks such a link, MediaWiki first checks that the page hasn't been created in the mean time, and, if it hasn't been, that the user is allowed to create and edit it:
If the page exists, the user is just redirected to the normal view URL for the page.
If the page doesn't exist, and the user is not allowed to create it, they're also redirected to the normal view URL, which then returns an HTTP 404 status code and a message saying that the page does not exist. (This is what will happen if you click the "like this one" link above, unless you happen to be an admin on Wikipedia.)
Finally, if the page doesn't exist but the user is allowed to create it, MediaWiki just treats the URL like a normal edit link and shows the edit form.
It looks like, for some reason, new users clicking the link to their own user page on your wiki are hitting case 2 above instead of the expected case 3. This might be a user rights issue: in particular, you should check that normal logged-in users (group user) on your wiki have the createpage permission.
If you want to allow normal users to create only their own user pages, there are ways to do that, but all that I know of involve either installing an extension or writing your own getUserPermissionsErrors hook. I can give you some examples of how to do that if you want, but it takes a bit of coding.
Those links are placeholders that you might want to fill in. They are provided so you can easily fill-in some important parts of your new wiki.
See http://www.mediawiki.org/wiki/Manual:Footer for a complete list.
There is actually no setting to disable them.
The link mentioned by Ilmari Karonen above:
Alternatively, since MediaWiki 1.17, you can also modify the footer by
defining a hook in your LocalSettings.php.
...shows how to add links to the built-in list of footer links. What it does NOT show is how to remove the existing built-in footer links, which is what the original question was.
Turns out it is a simple addition to the referenced hook solution. You just need to discard the existing footer links in the template array.
Most folks will not only want to remove the built-in footer links but also add their own. In the spirit of StackOverflow, here is a complete example solution that does both (this is from an existing Wiki...)
This works in mediawiki-1.29.2 but it will probably work in many older versions too. Put this code in your LocalSettings.php file (I put it at the bottom) to remove the existing footer links and add your own:
# Remove all existing footer links and add my own
$wgHooks['SkinTemplateOutputPageBeforeExec'][] = function( $sk, &$tpl ) {
# IMPORTANT: this is the secret sauce - remove all existing footer links
$tpl->data['footerlinks']['places'] = array();
# To add new footer links to local wiki pages:
#
# 1) You MUST create your new pages in your (Main) namespace first, for example:
#
# http://<your-site>/wiki/index.php/About_Us
# http://<your-site>/wiki/index.php/Contact_Us
# http://<your-site>/wiki/index.php/Disclaimer
# http://<your-site>/wiki/index.php/Download
# http://<your-site>/wiki/index.php/Privacy_Policy
#
# 2) You MUST then create each of these pages in your MediaWiki namespace:
#
# http://<your-site>/wiki/index.php/MediaWiki:Aboutpage
# - Insert 1 line, with "About Us" (no quotes)
# http://<your-site>/wiki/index.php/MediaWiki:Contactpage
# - Insert 1 line, with "Contact Us" (no quotes)
# http://<your-site>/wiki/index.php/MediaWiki:Disclaimerpage
# - Insert 1 line, with "Disclaimer" (no quotes)
# http://<your-site>/wiki/index.php/MediaWiki:Downloadpage
# - Insert 1 line, with "Download" (no quotes)
# http://<your-site>/wiki/index.php/MediaWiki:Privacypage
# - Insert 1 line, with "Privacy Policy" (no quotes)
#
# 3) Add new footer links like this:
$tpl->set( 'aboutpage', $sk->footerLink( 'aboutpage', 'aboutpage' ) );
$tpl->data['footerlinks']['places'][] = 'aboutpage';
$tpl->set( 'contactpage', $sk->footerLink( 'contactpage', 'contactpage' ) );
$tpl->data['footerlinks']['places'][] = 'contactpage';
$tpl->set( 'disclaimerpage', $sk->footerLink( 'disclaimerpage', 'disclaimerpage' ) );
$tpl->data['footerlinks']['places'][] = 'disclaimerpage';
$tpl->set( 'downloadpage', $sk->footerLink( 'downloadpage', 'downloadpage' ) );
$tpl->data['footerlinks']['places'][] = 'downloadpage';
$tpl->set( 'privacypage', $sk->footerLink( 'privacypage', 'privacypage' ) );
$tpl->data['footerlinks']['places'][] = 'privacypage';
return true;
};
IMPORTANT: Don't forget to follow the instructions and create your own pages and the corresponding MediaWiki redirects, or your links may not show or they may be broken.

Is there a way to tell Google, certain elements are irrelavent to page?

I have a page that shows the main product for that page, next to it though are "related products" which when you click on them you go to their page, and they have their own related products as well. The problem is that the related products are getting indexed by Google so when you search for product-A you may get the product-B page where product-A is a related item, instead of just getting the product-A page. I am trying to prevent this. Any ideas?
Thanks!
You can add rel="nofollow" in any links you don't want a bot to crawl. In this case, you can apply that tag to all your links and google won't follow them off your main page.
http://en.wikipedia.org/wiki/Nofollow
EDIT for clarification:
Page "A" is for widgets. You want this page to be returned for searches regarding widgets; on this page is a "related searches" section which links to Other Widgets. On all the anchor tags on page "A" which link to pages "B" and "C" (the related searches for Other Widgets), you'll put a rel="nofollow" tag. This will prevent Google from hitting page A and then following your "related searches" links off to pages "B" and "C".
This will NOT prevent pages "B" and "C" from being indexed on their own, it just prevents them from getting pulled in from page "A".
EDIT#2:
rel="nofollow" tells bots you don't want them to follow the link to the second page. Regardless of the anchor text on a link from A->B, if you've nofollowed it the bot won't "flow" pagerank to the linked-to page and should not follow the link to page "B" to index it due to that tag on the anchor. Note that this is not foolproof: Yahoo and other SE's may not treat nofollow like Google....so your best bet is to make sure that each page is strongly on-page-SEO'd such that it gets included in the index for the term you want it to be included for. Hope this helps...but like much of the SEO world there are few hard-and-fast rules which apply universally.
yes... put them at the bottom of the page for content,
if you want that to appear visually at the top of the page, use a css layout to re-arrange the page elements
also, as darksquid already said, add rel="nofollow" to links you don't want considered
another tip (pertaining to your comment on darksquid's post):
You could load the content via ajax, which would keep most search engine spiders from seeing it at all (since they don't generally execute javascript)
Use Google Applicance - googleoff / googleon Tags:
http://www.geekzilla.co.uk/ViewC8614968-56ED-4729-9C12-F01677DAC412.htm

Long forms best way to display errors. Usability Question

We have a long for which has 3 sections:
requester, shipping and billing
each section screen or more long so the form is 3+ screens long. From usability perspective what is the best way to display messages on the form.
Grouped list of error messages at the top of the form.
Grouped messages for each section at the top of the section
Error messages near to the form field which actually has the error.
Personally, I would like, at the top of the page before the form headers, to have something like:
There was an error with your form submission in the following section(s):
Shipping, Billing
Where Shipping and Billing are anchors that will take me down to that section of the form.
Then, above that section, have the relevant messages to that section:
Shipping
- You need to fill in an address
[rest of form here]
Billing
- You need to fill in a name
[rest of form here]
Grouped messages for each section at the top of the section
with a visual change to the form field which actually has the error.
I find it most usable if there is a generic error at the top of the form saying something like "There were errors submitting your information, please correct the fields in red" then show the more specific error messages next to each form field that had an error.
Roger Hudson has a very good article on writing accessible forms
and an example on error handling.
I like to have a dialogue that shows the type of effected fields, let's them click okay, then scrolls them to the first error in the form.
The affected field is then indicated with a flag/border/marker of some kind and a message letting them know the type of problem.
So, if they entered a malformed email address like "me#me'com" if would let them know the email address is malformed. The exact wording is really dependent on the type of user you are targeting.
I HATE forms that tell you there are errors at the top, then have tiny little asterisks by the fields.... ugh.
P.S. It also drives me nuts when a form has a "password" or other sensitive field and it gets emptied without marking it as a required, corrected field as well.

Resources