I'm eager to move towards a more standards-based, accessible and semanticly-correct web development approach. At the office, I don't expect there to be huge changes straight away, but I'm trying to start laying down some of the basic foundations for progress further down the track.
Part of this process is the introduction of the rel attribute in links and other such content. This extends further than the familiar old
<link href="mystyles.css" type="text/css" rel="stylesheet" />
which many developers would probably throw in without even thinking about it. I'm curious to know if anyone uses rel regularly in other ways. For example, setting your main navigation's link back to the home page with rel="start".
If you have implemented Link Relations in your own project, what prompted you to adopt them and what benefits were you trying to realise?
If you have looked at Link Relations but decided against their use, what was the basis for your decision?
I frequently use the rel (and rev) attributes with a wide range of values on both <link/> and <a/> elements.
I've outlined some of the more common (and more useful) relationship types below. A more complete list of rel values is maintained on the microformats wiki.
HTML 4
There are several standard link types defined by the HTML 4 specification.
alternate - Used when providing a link to an alternative version of an HTML document, for example in a different language or another format. This is most commonly used when linking to an syndicated (RSS or Atom) version of a web site.
next and previous - Used to indicate the next and previous documents in a series of documents. If rel="next" is used on a <link/> element then some browsers will pre-fetch the contents of the linked document (see the MDC link prefetching FAQ).
XFN
XFN (XHTML Friends Network) is a microformat used to describe the relationships between the people that are represented by web pages. It also allows a page to indicate other pages that represent the same person (e.g. my blog, my Twitter profile and my Stack Overflow profile all represent me). It does all of this by defining a set of rel values:
me - Used to indicate that the linking page and the linked page represent the same user. This is widely adopted by many social sites (including Stack Overflow) when linking from a user profile to the user's own web site.
contact, aquantance and friend - indicates that you know the person you are linking and how well you know them.
met - indicates that you have met the person you are linking to.
co-worker and colleague - indicate that you either work with or work in the same field as the person you are linking to.
co-resident and neighbor - indicate that you live with or near the person you are linking to.
child, parent, sibling, spouse and kin - indicate that you are linking to a member of your family.
muse, crush, date and sweetheart - indicate a romantic relationship with the person you are linking to.
These relationships can be parsed and used to determine information about a user, such as who their friends are or what other online profiles they possess. For more information on current, and potential future, applications of this the following pages might be of interest:
Ben Ward's article on Portable Social Networks.
The list of XFN implementations on the microformats wiki.
Other
There are various other link types defined by various specifications:
nofollow - Used to indicate that search engines should not follow a link when crawling a web page. See the rel-nofollow specification.
canonical - Used to indicate that another URL is the canonical version of the current page and should therefore be favoured by search engines. This is also used with the rev attribute to indicate an alternative, usually shorter, URL for the current page (i.e. rev="canonical" indicates that the current URL is the canonical version of the linked URL). More information and tools can be found in Simon Willison's blog entry on rev=canonical.
tag - Used to indicate that the linked page is a tag (i.e. keyword) describing the linking page. See the rel-tag specification.
license - Used to indicate the license under which the content of the linking page is released. See the rel-license specification.
I use the rel="nofollow" for user contributed links in blog comments. Google wont follow the link and it wont get a higher page rank because of the link.
One thing I've used them for is as a way to designate external links that should be opened in a new window. This functionality isn't possible with strict XHTML, because the target attribute is no longer allowed on <a> tags. But with some javascript and the rel attribute you can do a pretty decent job of it, as outlined in this article: New-Window Links in a Standards-Compliant World.
As Chad said, I use rel="external" to designate links I'd like to open in a new window (leveraging some jQuery to make it possible).
I also use rel="nofollow" when I'd like to make the bots that follow rules (like Google bot) not index my link.
It's useful on public websites to automatically add the nofollow, otherwise it could become enticing for spammers to make a link farm out of your blog comments, for example.
Related
So in gitlab you can use [[_TOC_]] to display a table of contents for the current page - which works on headings.
But I want to have a heirachy in my wiki like:
<home-url>/Project1
<home-url>/Project1/Tools
<home-url>/Project1/Debugging
<home-url>/Project1/Debugging/GDB
<home-url>/Project1/Debugging/MSVS
Such that in the Project1 page I get an index (links) to each section similar to the table of contents layyout - e.g.:
- Tools
- Debugging
- GDB
- MSVS
I can do this manually, but that's a pain to maintain. Is there some automatic tool to do this for me like TOC?
The TOC support steams from issue 2494, and was implemented in issue 21901, which gave us the Markdown [[_TOC_]] syntax.
Even the current request to support [TOC] instead (issue 14193) does not mention any layout option to include a hierarchical display.
As mentioned in the first issue:
If you need more control, you can open a new issue at https://gitlab.com/gitlab-org/gitlab/issues and upvote it.
For example: issue 215988: "Add Gollum depth level support for Wikis Table of Contents [[_TOC_]]"
Having the ability to limit a [[TOC]] depth is useful to show a more synthetic view of a page while keeping its deeply nested structure.
See also GitLab 15.3 "Visualize table of contents in the WYSIWYG wiki editor".
Thanks to VonC for the actual answer - i.e. there is not such a feature at the moment (well, not quite as I want it) - but there is the side bar in gitlab wiki which shows you the pages within your wiki.
If you structure you wiki into folders and subfolders then you can navigate with this side bar "tree". Its not collapseable - so its just a bog-roll off text, but it is indented to aid navigation.
It works well enough for simple wikis with a few dozen pages - but probably if there are hundreds of pages it might start to breakdown - at that point you might want to break your wiki up into several wikis with a top-level links page or some such.
Here is (a crap) picture - it was the best I could see on google without looking too hard see here
You get this for free (without doing anything) so its decent for most cases.
One of my colleague left on vacation and left me with an Orchard project to work on.
I never worked with Orchard, so please excuse my ignorance and my possibly stupid questions.
I come to you for general advice on how to implement and structure the content of my site, as my research didn't give me the answers I'm looking for.
Here are the requirements:
The site must be divided into sections (section A, section A-1, section A-2, section B, etc...)
The navigation of the site must be based on the sections, each navigation item must also contain an image
Each section has a separate page with roughly 4 types of content that must be displayed:
Title of the page
Articles associated with this section, which represent the main content
FAQ content associated with the section which should be displayed in a specific zone
Miscellaneous content associated with the section which should also be displayed in a specific zone
I'm struggling at nearly every aspect of the requirements...
We started building a taxonomy, with as many terms as we have sections, allowing us to build the hierarchy we want, which is perfect. But this had 2 downsides:
The built-in taxonomy-based navigation is static, so the only thing displayed is the term, and we couldn't find a way to change it so the user would be able to add an image to the taxonomy term.
The generated pages based on the taxonomy display every content item based on the current term, that is, the articles, but also the FAQ content and the miscellaneous content, all in the Content zone.
Is there any way to work around these issues by using the built-in taxonomy? Or will I have to build content types from scratch in order to achieve what I'm trying?
The solution my colleague came up with was to add a layer for each section, and add in this layer 3 widgets, one for each specific content (title, FAQ, misc) in different zones. But I don't think this will me maintainable, as we currently have 4 main sections, each with 4-5 subsections, so that's rougly 60 layers, which will be a nightmare for the client to maintain.
Any advice will be greatly appreciated, I'm kind of lost.
Thanks in advance,
Mickaël
Taxonomies was a good start, but now you need to study projections. You'll be able to set-up filters about what you display.
For adding an image to your terms, one way to do it is to add a media library picker field to the type that was created for your taxonomy.
For an academic plone site I am creating, it is desirable to support document tags (see below).
There are multiple users for this site, and each user has a (long) list of publications that they alone can add / edit.
In its simplest form, a publication entry consists of a hyperlink or even just plain text. For instance:
A. Baynes, J. Watson and S. Holmes, "The role of observation and deduction in forensics", Applied Crime Solving, 221, 210-243 (1901). doi: 10.1032/acsolv2714
(The above is a fictitious article, but it has all the elements one expects in most citations.)
For those unfamiliar with DOI links, these are fixed text strings that can be resolved to the page for the article in question using dx.doi.org. Further, copyright / license terms often prohibit the authors from providing a full PDF / HTML for their articles on their websites. The articles often lie behind a paywall (usually accessible from most Universities / major research labs). So, running full text searches on the article itself is NOT an option.
Returning to the problem definition, I am assuming that the users will add their publications as links, but I want to give them the ability to specify a comma separated list of words / phrases (or tags) that more closely identify what the article is about.
For the above article, an appropriate list of tags would be:
forensics, haemoglobin, degradation of evidence
After each user appends such tags to the article, I want to create a backend that will allow visitors to the site to simply be able to enter these tags in a search field and find all publications that pertain to, say, haemoglobin.
That search should pull all publications that list haemoglobin as a tag, for all users of the site.
I intentionally used haemoglobin as a tag to illustrate that relevant tags need not be (and usually aren't) part of the text specified in the title of the article.
Further, the Plone "Collections" feature is not an adequate solution to this problem. Collections are typically generated by the admin. That means that a) admin intervention for something like this is essential and b) tags are best defined by users, not the admin.
When adding any content type (File, Folder, Page, Link, Collection, ...) in Plone, you can apply any number of tags to the content. This is done in the "Categorization" tab when editing/creating the content.
Visitors/Users can search the site based on tags like normal searches (using the search box or accessing the /##search URL).
Moreover you can use "tag cloud" portlets to visualise the tags' frequencies. Check the followings to get an idea:
1. A tag cloud portlet that rotates tags in 3D using a Flash movie
2. TagCloud
Don't forget to check Plone documentation, and specially Plone user manual to get yourself acquainted with the way Plone works.
#user2751530
I would like to know whether you are still working on this specific project - I am currently developing a similar one using plone v4, documentviewer v3 and an as of yet nonexistant frontend. I would like to discuss different approaches to the tagging-by-user problem, you can contact me through skype (dawitt19) or twitter (pref.) through #japhigu.
I have seen many somewhat similar questions, but nothing quite what I'm looking for. So at the risk of being told this is a duplicate... here it goes.
I've found that there are times I have a node that simply contains content that will be displayed somewhere else, but shouldn't be viewed directly. That is, no one should ever go to node/1234, but the content in node 1234 should be displayed somewhere else.
For example, I create an about page with tabbed content using views. So there are "About Me", "About Us" and "About Them" pages. All of these are displayed in a single page with tabs using Views. So I don't want people to get directly to the "About Us" node because then they wouldn't see the tabs for the other pages. At the same time, I don't want Google giving people a direct link to this node, I want to limit access so users can only get to it through the View (i.e., the tab).
So I need to restrict access to the node, remove it from the Drupal search results, and make sure Google doesn't pick up on it. Any suggestions?
---- Note ----
I've accepted the answer from mingos (thanks btw) because even though it's not a full answer / solution, it gave me some good things to think about. Additional answers are still welcome.
In Drupal 7 you can use: http://drupal.org/project/internal_nodes
Description: Some content/nodes should never be viewed directly; only visible be through something else such as Views or Panels. This module denies access to node/[nid] URLs while allowing the content to stay published and otherwise viewable.
Full disclosure: I am the creator and co-maintainer of Internal Nodes. I found this question while searching to see how the module could be found on Google.
Tough one.
If you want to have many nodes like this and do the "displaying elsewhere" dynamically, I can't think of anything right now (at 2:20 AM I rarely can).
If there is onne such page (or very few), I'd restrict access to it by any available means (Permissions, Nodeaccess, Content Access, TAC, whatever) and then create special themes for the pages where the restricted content should be displayed. The themes would contain database queries, fetching content from the restricted nodes.
Other possibility might include creating a special theme for the hidden nodes in question (perhaps all belonging to the same content type?). Make full node display nothing (or a message saying the access is restricted) and add a ROBOTS meta tag asking Google not to index the page. Make the teaser view available though - you can display it freely inside a view, but since /node/1234 is the FULL view, the actual content will be unavailable here.
Dunno if this solves your problem, hope it helps at least a bit.
I found this page after running into this same problem.
What I found worked for me might be part of the answer you need:
Take a look at the Page Manager Redirect Module http://drupal.org/project/page_manager_redirect . I just started playing with it.
It uses the Page Manager module of CTools to redirect one page to another. What makes this most powerful is that Page Manager uses Contexts. So, if you want to redirect all pages of a particular content type, you can do so.
I just started to use it (instead of Taxonomy Redirect and Path Redirect) to redirect (301 response code) my taxonomy terms for a particular vocabulary to particular nodes.
In your instance, you should be able to use contexts to filter for specific pages.
Of course this doesn't solve the problem of these nodes coming up in search results.
There is also another module Rabbit Hole which has a similar functionality like Internal Nodes but works for all entities, not only nodes.
I am having the same problem, and are currently thinking of the following solution where all the content of a node is to be displayed to certain users (permission based):
- unpublish node
- create a new published checkbox
- create a view with fields that shows alle the content
Haven't tested it thoroughly yet, but it seems to work.
The node is to be displayed to the creator (only one in permission 1), some of it to permission 2 and all of it to permission 3.
Any comments on this solution.
I assume this will also exclude it from search, but permission 2 and 3 needs to be able to search it. Still haven't figured that one out.
I used Rules module with an "entity is of bundle" and the built-in "Page redirect" action.
There is a really easy way to do this if you only want to show a content type through a view.
create a content type as and make it unpublished.
create a view and on the filter option set the filter to "Content: Published (No)"
the view will give anon users access to the content through the view but they won't have access to the unpublished content at the direct link to the content.
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.