Leaderboard

ProcessDateArchiver ProcessWire Date Archiver Process Automatically archives pages based on a Datetime field (e.g. /news/2013/01/03/some-news-item/). Behavior - When you add a page with a specified template, the module will automatically create year/month/day archives for it. - When you change the date in a specified Datetime field, the page is automatically moved to the correct year/month/day archive. - When moving or trashing a page, the module will automatically clean up empty year, month and day archives. How to create an archiving rule 1. Go to the Setup -> Date Archiver screen in the ProcessWire admin. 2. Click on Add New Archiving Rule. 3. Specify the template that should be archived (typically the news-item template). 4. Specify the Datetime field that should be used to determine the date to archive by. 5. Specify the template that should be used for creating year archives. 6. Optionally specify the template that should be used for creating month archives. 7. Optionally specify the template that should be used for creating day archives. 8. Click Add Rule. Tips and tricks - Configure the archive templates that will contain other archives to sort its children by name. - Configure the archive template that will contain the news items to sort its children by the specified Datetime field. - You will improve usability if you dont allow the user to create date archives manually. How to Install 1. Install the module by placing ProcessDateArchiver.module in /site/modules/. 2. Check for new modules on the Modules screen in the ProcessWire admin. 3. Click Install for the Date Archiver Process. Module download: https://github.com/u...hive/master.zip Module project: https://github.com/u...ssDateArchiver/

Matthew, regarding the Happy New Year links: I thought that either you were kidding, or you weren't and could use a laugh. So I manually linked them myself, just for fun. I did a search for "worst designed websites ever" and used those for the links. Sorry guys, my sense of humor sometimes gets the best of me. I'll unlink them. With a clearer head this morning, it seems clear that you really are seeing actual spam links and you aren't kidding? It really does sound like browser spyware to me. Also, you mentioned this Skimresources thing, which I'm not familiar with. Can you explain more about where you are seeing this? We are not using any affiliate networks or advertising here, so this is not coming from processwire.com (unless there's some problem with IP.Board). I'm guessing you've got a browser extension that is inserting <script> tags into sites that you visit to automatically link words. Can you try from another browser to double check? For instance, if in Chrome, try Firefox, etc.

Interesting, but too little too late as far as I'm concerned. I was all set to build my first EE site a month ago when they pulled that "license simplification" malarkey overnight, which sent me on a lengthy exploration of various CMS systems and eventually led me here. I can't really think of a reason I'd ever go back.

Hello again vanni, I think many of the TxP folks who have migrated over to PW have been in the same position. Take Tom Reno (renobird) for example; he's become very capable with PHP thanks to having to learn PW templates in a short period of time. There are good resources to help with this; template documentation on the main site, clear code examples on the forum (just browse for a while or google for them), an amazing blog profile for PW with lots of templates to use, an IRC channel and tools like Soma's cool API cheat sheet. Whilst TxP's parsed template tags are easy to use if you are used to writing X/HTML documents, you often have to spend time digging into the tag or plugin documentation to find out which attribute does what. With PHP you will have to learn some new things too, but once you know them you will have additional flexibility for your template handlers that isn't available without custom coding stuff in TxP and you will have a transferable skill which you won't have if you are putting time into learning TxPs unique tags. In addition, using PHP as the template language means the templates don't need to go through an additional parser.

I wanted to give you a little preview of a new module I've been working on recently: the Form Builder module. This module lets you create simple-to-complex forms and place them in your site without any need for development. In this video we show how we can create, publish and test a simple contact form in less than 5 minutes. Then we take a quick look at a more complex form (already produced). I recommend viewing the full screen + HD 720p version so that you can see it more clearly than in this small forum embed. (note: there's no sound, so no need to adjust your volume) More about the Form Builder The Form Builder has many options for the developer to customize output and create their own themes, markup, etc. But the goal here was to build something that could enable you (or your client) to publish a form in less than 5 minutes, so that's the focus of this video. This tool is literally easy enough for your clients to create and manage their own forms. Or from a developers perspective, it takes something that used to consume hours and makes it happen in minutes. Form results save in the database and optionally can be CC'd to you by email. Result entries and be viewed, filtered by date, and even edited in the admin. You can export results to a spreadsheet as well. I'm working on the ability to export to pages, though that isn't quite ready yet. How the Form Builder will be licensed This module will be individually licensed on a per-site basis for a small license fee. It will also be available for free personal use to established forum members. Basically, I want to see if I can substitute some of my client work to focus on ProcessWire instead. And in order to do that, I need to have an income (I have a family to support). So I thought that building a special tool like this would be a way to make a go of it. A lot of you have asked to make donations to the ProcessWire project, and while we still won't be able to take donations, you will be able to support the ProcessWire project by purchasing and using the Form Builder in your own client projects. So a lot of motivation for this module came from wanting to provide something really special for all that had wanted to support ProcessWire. After a few months of work, I'm pretty happy with how this module has turned out -- it's already saved me tons of time in my client projects. So I'm thinking and hoping you guys will really like it too. I look forward to your feedback.

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

This module creates a page in the ProcessWire admin where you can test selectors and browse page data and properties without editing a template file or a bootstrapped script. Given selector string is used as is to find pages - only limit is added, if given. Errors are catched and displayed so anything can be tested. Pages found with a valid selector are listed (id, title) with links to the page. I was thinking this would be useful for someone new to ProcessWire, but it turns out I'm using it myself all the time. Maybe someone else finds it useful as well. Module can be downloaded here: https://github.com/n...essSelectorTest Modules directory: http://modules.processwire.com/modules/process-selector-test/ Features Edit selector string and display results (and possible errors as reported by ProcessWire) Explore properties and data of matching pages in a tree viewLanguage aware: multi-language and language-alternate fields supported Repeater fields and values Images and their variations on disk More data is loaded on-demand as the tree is traversed deeper Quick links to edit/view pages, edit templates and run new selectors (select pages with the same template or children of a page) Page statuses visualized like in default admin theme Add pagination Screenshots

Page Link Abstractor module for ProcessWire 2 Plugin module that lets you move pages in your site without worry of ever breaking static links on other pages. Download at: https://github.com/ryancramerdesign/PW2-PageLinkAbstractor What it does Converts links in textarea/rich-text fields to an abstract format for storage, and converts them back at runtime. This means that if you move a page and another page is linking to it, the link won't be broken. It also means you can move your site from subdirectory to root (or the opposite) and not break links you may have created in your textarea fields. This applies to any kind of links: pages, files, images, etc. This module will also notify you when you edit a page that has a link to a page that doesn't exist or is in the trash. This module has been tested with ProcessWire 2.1 but should also work with 2.0. Since this module has not yet had a lot of testing, it should be considered "beta" and use is at your own risk. Please let me know of any issues or bugs you run into. How to install 1. Download the PageLinkAbstractor.module file from https://github.com/ryancramerdesign/PW2-PageLinkAbstractor and place it in: /site/modules/ 2. In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. 3. Now scroll to the PageLinkAbstractor module and click "Install". 4. Edit any of your textarea fields in Setup > Fields. You'll see a new configuration option to enable this module for that field. How it works This is a technical explanation for how this module works for those that are interested. Reading this is not required in order to use this module, but it may help you to use it more effectively. When you save a page that has a textarea field with this module enabled, it will look for URLs in HTML attributes by looking for an equals sign followed by a URL. It replaces instances of your site's root URL with a special tag: {~root_url} Next it checks to see if any of the URLs it found can be loaded as pages in your site. If so, it replaces those URLs with this special tag: {~page_123_url} where "123" is the Page's ID. When the page is loaded, ProcessWire does the opposite and converts those special tags back to their URLs. Because the URLs were abstracted to tags that are generated at runtime, when a page (or a site) is moved, no links are broken. Note that this module only converts URLs to tags when you save a page, so it only affects pages saved after the module is installed. Where to use it This would be most useful on your main 'body' field that uses a rich text editor (like TinyMCE). Where not to use it There is some overhead in using this module that will be insignificant if you use it carefully. Here are a few instances to avoid using it: Avoid use on fields that have the 'autojoin' option on, unless your site doesn't load lots of pages in a given request. Don't use on textarea fields that can contain anonymous (guest) user input. Avoid use on fields that aren't likely to contain links to local site pages in HTML markup. No need to have this module parsing things unnecessarily. Avoid use on fields where you think you might disable it later. Once disabled, the abstract tags representing the URLs will still be in place. If the module is disabled, those tags will no longer be converted to URLs are runtime. You would have to correct them manually by editing the page. Side benefit The tags that this module abstracts to are intentionally fulltext indexable, so you can perform searches for these tags. This means that you can find all pages linking to another by searching for it (minus the brackets and "~"). For example: $links = $pages->find("body~=page_123_url"); That would return all [viewable and visible] pages linking to page ID 123. Please note In order to convert URLs for pages, this module needs to load those pages in order to obtain their URL. If you are linking to a hundred pages in your 'body' field, you should expect that it may slow down the page 'load' and page 'save' time for pages containing lots of links. This module doesn't yet abstract local URLs that have a schema/protocol and domain in it. It just works with path-type links like /path/to/page/ and not http://domain.com/path/to/page/. This module hasn't yet been tested with migrating a site from subdirectory to root, but I will be testing this soon.

Just thought I'd share an idea that has popped into my head a few times by now, while working with PW. The purity of the central tree data-structure that powers the ProcessWire data-model, is very elegant, and for the most part works really well for me. One instance where it does not always work well, is in terms of optimizing URLs. Most of the time, simply having items grouped under other items works quite well, but at other times, you can end up with URLs that are littered with keywords that aren't really relevant. Not great for SEO, and not always great for URLs you intend to share via various channels. (Twitter, printed material, etc.) This happens with deeply nested menu structures in particular. On one site, I ended up with a URL like this: "/articles/some-topic/some-page/" - the keyword "articles" has no particular relevance here, it's just a logical grouping, not something you expect people to search for. And "some-topic", in this particular case, was unwanted. The client was asking for a short, user-friendly URL, e.g. "/some-page", and in order to do that, he would have to place the actual page in the root of the site, which was not appropriate in this case. So this brings me back to an idea I've been kicking around (for my own CMS) for some years - the idea of having more than one hierarchy. Actually, an arbitrary number of user-defined hierarchies - with the ability for the user to place a given page in either one or more of these hierarchies. I've had various versions of this idea over the years, but in the simplest version, one of these hierarchies is the designated URL hierarchy - so this would be the hierarchy ProcessWire has now. Other hierarchies are just logical (taxonomic) hierarchies that could be used for whatever purposes you like. So as an example, "product categories" might be a dedicated arbitrary hierarchy, in which "product" pages can be organized logically, independently of the hierarchy that drives the URLs. If somebody is selling iPads, for example, you can place the product in the "product categories" hierarchy, e.g. "tablets/apple/ipad/32gb", which might determine where the product appears on a menu, but does not affect it's URL. This particular product might be placed in the URL hierarchy as simply "/apple-ipad-32gb", for example. (maybe not the best example, as in this particular case, it might make sense to include all the keywords from the category - it's just an example.) This problem could also be addressed, apparently, by allowing a page to be referenced more than once in the tree, or by introducing an "alias" template, so that you can "optimize" URLs by creating "aliases" for pages in the tree. Mathematically, this solution doesn't speak to me - in a real tree, a node should have precisely one parent, otherwise you introduce the potential for things like circular references or circular queries, e.g. traversals like A->B->C->A->B->C->... Or, in the case of aliases (as opposed to references), you introduce "dead" nodes from which you cannot traverse or find subpages, because the "alias" node is a leaf-node, even if the page it references has children. (otherwise, mathematically, it would be a reference and not an alias.) Another possible solution would be to simply allow a custom URL alias for any page. This would probably be relatively simpler to implement, perhaps as simple as adding a "URL alias" text-field to templates that need it, adding a very simple module that does a query for the exact value of that text-field prior to PW doing it's normal traversal and dispatch. (This might not be great for SEO though, as you end up with two URLs for the same page.) Clearly that's a much simpler solution than introducing multiple hierarchies, but for other reasons, the idea of multiple, user-defined hierarchies has always appealed to me. For one, it's not uncommon for the same page to appear under two different menus. As an example, on a site I'm building right now, some blog-posts double as articles that also appear organized somewhere in a category on the main menu. It's the same logical page, and it should have the same URL, regardless of whether you found it in the blog-roll or on the main menu. But because the logical and URL hierarchies are one and the same, there is no simple way to accomplish that. Perhaps the best real-world example I can give, is a product catalog - for one company we worked with, their products were organized by two entirely different hierarchies, because their products are used in two entirely different industries. So you have two independent logical hierarchies, but the pages (and URLs) are the same. I could provide more examples, but I think I've made my point, so I'll leave it at that. Is multiple hierarchies a good solution, or is there another, simpler, more direct solution to these issues?

I think that people spend entirely too much energy on optimizing URLs. It almost doesn't matter, after all - I feel that there is virtually no chance somebody will enter the URL manually (except the index page, maybe). My opinion is that multiple hierarchies = bad. Simple as that. But you have valid use-cases (or problems), so I can try to give you my opinion. [simpler URLs (for blogposts)] I see two options here: I'd either code the root page as a router of sorts (with rules given in case of collision), or didn't simplify the URL up to the root: domain/articles/this-is-article, or domain/topic/this-is-article, or even domain/a/this-is-article would work for me; I'd probably go with articles, because it's most logical - therefore articles will be both article router AND content holder. [simple URLs (eshops)] This is practically the same situtation [Different menus] If somebody wants to build menus manually (and I doubt that), then PW probably might not be ideal tool, but having some 'Custom-menu' tools page seems like a good solution here. And if you want your menus automatic, then I see no problem having millions of menus: if the menu is automatic, there must be a way to describe which content goes there, and then it's a simple problem of coming up with the right query. [Example: catalog] This is precisely the thing I'd build with one catalog and two router pages with using URL segments on (or, if it was simpler, just one 'router' page, and the other industry would have the 'real' tree), and possibly on module for generating the menus (again, there must be a way to tell the computer how you want the tree to be created and/or modified) Generally speaking, I think it's less about the hierarchy and more about the context; and there are almost always ways to give user more context other than multiple hierarchies. --- Edit: Reading through Antti's link, it seems that I echo Antti's and Ryan's opinion

That response doesn't make much sense me, but I don't know what their protection is. Images are physical and there's nothing more special about it, than if you'd put a static html with an image that lives in a folder somewhere. Adding this to after the "RewriteEngine on" in the PW .htaccess will protected any image request that does not come from the domain specified. Works well. RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.ch [NC] RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

I just couldn't imagine anyone paying that kind of money for support that isn't even open on the weekends. What happens to the guy that pays his $1900 payment for 10 months and finally needs "urgent support" at 5pm on a Friday? Crazy...

Omg the internet is full of links!!

Matthew, you really need to clean your firefox...

HI Kevnm, welcome to the friendliest (and occasionally silliest) forum in existence. Sorry everyone is so late in answering your post ... must be faster!!! (Or, in my case, would help if I was younger and cleverer!) You are right, there is no paid or guaranteed support with ProcessWIre (though as it grows bigger I am sure someone somewhere may start supplying such a service) and as such is a different business model. But I have to say, these are some of the most responsive forums I have ever come across - though quite what would happen if 10,000 users turned up with question ... *gulp* Still, the look on Ryan's face would be worth photographing. I think there is an interesting on going general discussion about support throughout the business sector generally. I tend to use my brother as a bench mark. Despite having been very senior in Sun Microsystems in the UK and Xerox, he is not technical, and now that he runs a boutique with his wife he is relying on local support for computers and websites and so on. Generally speaking the phrase "I am getting ripped off" seems to turn up regularly. And, as he has found out to his cost, you are not to know the true quality of that support until you actually need it. In his case, two years into a project, something went wrong and the monthly support fee he had paid did not match the fact that the company could not solve his problem. (I solved it for him in 2 minutes flat eventually, and I am not an admin by any stretch of the administration.) If you pay $2000 a year to a company for support, at the end of the day you have to make sure that you are actually getting your monies worth. It should not be some over priced insurance system, it should be paid for work. If you are paying a lot more than that, then the company better have some amazing reasons for charging so much. I have no idea whether EE is good value or not (I have no way of judging) but it certainly is the case that if they lose people from the bottom of the ladder then they risk loosing future big spenders, which may be why they have had a change of heart. Have fun with PW - the rest of us are!!

The main problem is the number of files not how large the folder in MB actually is. Try to upload 700mb in one file via FTP and then upload 700mb splitted into 2k files, you would see the difference

Ok i found out the solution, using start=0 inside the selector

Just updated these formatters for textile v2.5.1 which was released about an hour ago. HNY!

First day of the year here in "old" England. Spent it rigging up a little dev server with Ubunto, Webmin/VIrtualmin and Samba and then trying to work out why it doesn't work. Oh, joy..... PS: Now I am just going to set up a couple of PW thingies as Server Templates for quick developinginging... Joss HNY - (Abbreviated to help those infested with spyware...)

The ProcessWire 2.3 installer now lets you set the admin URL as part of the install process.

Hi antknight That wouldn't work - like I wrote that would produce an error 500. However, I found the cause of the problem in the .htaccess file: #Options +FollowSymLinks Once I commented out this directive, the problem disappeared. I found the solution here: http://www.wallpaper...pache-t718.html And a general explanation of the directive here: http://www.webmaster...orum11/1962.htm I hope this helps others with the same problem. /Allan

Greetings, I use this logic extensively in my sites to display only those articles that have a certain checkbox checked. I think of this as a way to create "instant categories"! Here is an example of the code I've been using. In this case, the organization has several "events" (each with its own checkbox). In the example below, the template displays a series of "intro images" only for "annual festivals" (in other words, the user checked "annual_festival."): <?php $eventlist = $pages->find("template=event, annual_festival=1, sort=-date, limit=50"); foreach($eventlist as $event) { ?> <div id="listings_box"> <img src="<?php echo $event->intro_image->size(300, 225)->url ?>" /> </div> <?php } ?> It works great! In your case, once you find the pages that are checked according to your requirements, you can then call the relevant text field. Thanks, Matthew

If you add an images field to a template say: "basic" template ( the name is up to you. ) Then, a page using that template wil create a folder in: /site/assets/files/id-of-the-page/ and put those images in that folder. So basically images are attached to a page. ( Not that you ever have to know where the images physical are stored ) To use those in tinyMce, you have to click on the image button. If you want to reuse images, say you want images for a header, storing those images in the home template could be a nice option. Then assumed that your images field called images is populated with images and is the home page, you can get those images in every page like: $home = $pages->get('/'); $imagesArray = $home->images;

Welcome henriette. There's several ways to archive what you want. Your ideas are on the right track, you definately want to create some "/footer/" page where you could enter the content for your footer then output the content of that page. http://processwire.c...-settings-page/ Single page approach: If you create a template "footer" and in the php file you just would output the markup and data of the page. You can make this page "hidden" to not show up in navigation. Then in your main template, where you would include you just render the "/footer/" page like this. echo $pages->get("/footer/")->render(); and the footer page template would be this (just example. <div id="footer"> <?php echo "<h3>$page->title</h3>"; echo $page->body; ?> </div> Subpages or repeater approach: You could use repeaters or just subpages to create the 3 blocks. Repeater module is a great way to "repeat" a set of fields. It is not installed by default. See infos here: http://modules.proce...dtype-repeater/ If using subpages you would create children pages under maybe a page "/footer/". Then output them like this. $blocks = $pages->get("/footer/")->children('sort=sort'); foreach($blocks as $block) echo $block->render(); If using repeater, it would be slightly different, but the repeater field is like a field that holds pages, but since you can't use render you'd have to output markup too. If repeater field is named "footer_blocks" with title and body field inside you'd do it like the following: $footer = $pages->get("/footer/"); foreach($footer->footer_blocks as $block) { echo "<h3>$block->title</h3>"; echo "<div class='footer-body'>$block->body</div>"; }

Hi Henriette I have done a similar thing on a site I am currently working on. There are a lot of ways you can do this. Here is a very basic version: Create the fields for your three blocks - call them Block Title 1, 2 & 3 and Block Body 1, 2 and 3. Create a template that includes these fields. Now create a new page Called "My front Blocks" (I am being really predictable here) and use your template. Go to Settings on the page and make it hidden (it should be published, however). Now fill in your information. That has given you the block content. You now need to call it into your footer. In each position You need to call in the fields from My Front Blocks: <?=$pages->get("/my-front-blocks/")->block_title_1 ?> <?=$pages->get("/my-front-blocks/")->block_body_1 ?> And so on. I leave the layout to you! You can do the same thing with a lot of other info while you are about. I create a page called Site Settings (with a matching template) and I put things like meta keywords, banner, blocks, site title, reusable phone number, anything that I may want to use all over the place. And then just call them into a template. Getting really clever If you want to go completely mad, you can create blocks template ( and associated blocks.php template file) and then create lots of blocks as pages, preferably as children to a hidden page like "blocks" In your Site Settings template or where ever, you can then create a Page field type for each block (choose single and null on the details tab) and set the parent to Blocks and the field to select - a drop down, basically. Now, one your Site Settings page, you can use the dropdown to choose which block you want for each position. Your blocks.php template file will take care of the layout of the block information, you just need to call the pages fields into your footer. For instance: <?php echo $pages->get("/site-settings/")->name_of_pages_field->render(); ?> The render() will then render the entire contents of the blocks page. Does that help? Joss

I haven't actually ever used CURL other than copy/paste from examples, so don't know what the proper method is to make it behave the way we'd want. I've always avoided CURL just because the examples always look so darn cryptic. But PW now comes with a WireHttp class that uses sockets and should give us an independent way of handling this stuff that doesn't rely upon allow_url_fopen or CURL. Actually, it attempts to use allow_url_fopen, but if the option isn't there, it falls back to using sockets. Meaning, it should work anywhere. The equivalent of your CURL example would be this: $http = new WireHttp(); $data = $http->get($url); // for a GET request // ...or... $data = $http->post($url); // for a POST request Should any GET or POST vars need to be included, then they must be passed in an array as the second parameter: $vars = array('foo' => 'bar'); $data = $http->get($url, $vars);

Correct me if I'm wrong, but what Google doesn't like are 302s. 301s aren't themselves bad, but can be less helpful to pagerank when stacked. I don't agree with the broad statements of the linked article. A properly used 301 is in fact a great thing for SEO. But also something to be careful with if you want to maximize the value of it. My experience has been that proper use of 301s is one thing that separates the good SEOs from the unknowing ones. They enable you to relocate URLs in a manner Google will transfer pagerank through. They also enable you to ensure people are always arriving at a consistent URL, thereby making it extremely likely that people will link to you in a consistent manner. Lack of properly used 301s increases the odds of diluted pagerank and duplicate content penalties. When someone loads domain.com in their browser and it 301s to just www.domain.com (or the opposite), thats a good thing. When someone types www.domain.com/about-us in their browser and it 301s to www.domain.com/about-us/, that's a good thing. When you have an old About Us link at domain.com/page.php?id=123 that 301s to www.domain.com/about-us/, that's a good thing. This is all good for SEO and good for the users. If this is consistent and stays that way, the external links that you build up over time will also be consistent. The pagerank that you accumulate over time will be maximized, not diluted. And what rare external links that point to content at an inconsistent URL will be identified as such by Google while still transferring pagerank. Where benefit starts getting lost is when you use 301s in a manner that sends it through several paths. My understanding is that Google does dilute pagerank somewhat the more 301s it has to go through in order to meet a request. Example: link points to domain.com/page.php?id=123, which redirects to www.domain.com/page.php?id=123 which redirects to www.domain.com/about-us which then redirects to www.domain.com/about-us/. The user still gets to the right place (good) but the pagerank value of the link that was pointing to domain.com/page.php?id=123 has been diluted to some extent (though don't know how much). Meaning, lost potential, but certainly better than a 404. A smart SEO keeps tabs on this stuff and corrects the first 301 to redirect to the proper URL rather than having to go through further unnecessary 301s. Pagerank potential gets maximized rather than diluted. The use of a slash vs. non-slash shouldn't be a factor for SEO, so long as it's consistent and 301s to the proper version (excluding root level of course). When someone is advising you to always use trailing slashes, I think this is what they are really saying: 1. Always be consistent in how you link to your own pages (regardless of slash standard). Preventing an unnecessary 301 here reduces the chances of some other 301 getting stacked on top of it. It maximizes the value of the link. 2. Standardizing on a trailing slash reduces the chances of having to implement more 301s later (further reducing the chances of a 301 stack). From an SEO standpoint a trailing slash will scale better because there is no functional reason to ever have to change. Whereas, without a trailing slash there is potential for having to change to one in order to accommodate future growth. I keep up with SEO stuff, but it's not my full time job either, so someone correct me if any of this has changed.