Breadcrumbs (how-to), and what it says about the system

[ryan]

I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with.

The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here.

:




<?php

foreach($page->parents() as $parent) {

    echo "<a href='{$parent->url}'>{$parent->title}</a> ";

}

You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. 

Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through:



<?php

foreach($page->parents()->append($page) as $parent) {

    echo "<a href='{$parent->url}'>{$parent->title}</a> ";

}

The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. 

Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.

[almonk]

Great post Ryan.

Coming from both a EE and Symphony CMS background, Processwire is a huge improvement in managing page content (in Symphony, it is so hard to manage a simple brochure site that it is almost not worth doing). The simplicity of Processwire all the way through its core is definitely the most attractive thing about this application, and I admire your clear hard work at creating such a powerful and yet, basic system.

(Not knocking Symphony here, it is exceptional for other use cases, but the majority of sites that I build as a freelancer lend themselves much better to Processwire)

[ryan]

Thanks for the feedback, glad that you are finding a lot of sites to be a good fit to develop in PW. I've not yet had the opportunity to try out Symphony, but had heard good things about it (and like what they've done with their site). Still glad to hear that PW makes it easier to manage page content. I remember several years ago there was a fairly impressive new blog platform that came out called Symphony (not sure where that went)... and then there is the Symfony framework (different spelling). A little confusing, but it is a good name.

Even though I've not used Symphony, I have used quite a lot of other CMSs. EE was one of the more frustrating to me because there was so much to like about it (people, CodeIgniter, design, company), that you are willing to go further, invest time into it and look past some of it's strange ways.  So the "deal killer" moments came later and were a little more frustrating. I think those "deal killer" moments are different for every person, so it's not to say anything bad about EE other than relative to what I was looking for (and I'll still use it when the project requires it). But now you have to invest money in it before you can even try it. I suspect this is why they don't have a free demo version of EE2 anymore (they did for awhile). With the current CMS landscape, one probably isn't going to be willing to invest the time to figure their way around the odd complexity of EE unless they've already bought it (IMO). And once you've invested that time to really learn it, at least it doesn't let you down–it gets the job done. But it hurts that portion of the audience that seems convinced they are locked-in and incapable of learning anything else.

[diogo]

It's not the first time i read about symphony on processwire forums, and thought i could tell something about it. I was trying symphony before i discovered processwire, and besides the obvious differences (starting by xslt/php templating systems), both have one important thing in common, they give you complete responsibility for the markup and great flexibility on constructing your website. For me, the problems with symphony is that the xslt can get quite complex (although i love how the xml data is thrown at the pages, and how you can check and easily get any node with their debugging tool http://symphony-cms.com/learn/concepts/view/devkits/), and i wonder if it make sense to output in pure xml when using html5 (there are big discussions on symphony forums only on how to output the doctype). Where i think symphony beats processwire is on the flexibility it gives the developer/designer, not only on building the markup and the front end structure, but also on building the backend structure, allowing him to build the forms independently from the pages, and presenting them to, or hiding from, the client/writer with the structure and organization he wishes. This flexibility is achieved basically like this: sections(fields) >> datasources(xml) >> pages(xslt) (http://symphony-cms.com/workspace/assets/learn/visual-overview-1258682736.png). I think this is very powerful, and maybe i'm wrong when i assume processwire doesn't achieve this kind of flexibility on the back end. It will be perfect when it does

[ryan]

Thanks for your feedback. This is an interesting topic,  and I'm not sure that I totally understand what you are saying, and may need more context. But looking at the diagram you linked to, it reminds me of why ProcessWire was built in the first place. I'm equating their 'sections' with templates in ProcessWire. But their definition of templates are also something separate beyond that, and 'entries' are a separate entity from 'pages' (if I'm understanding it correctly). While the terminology is varied, this is what I was describing as one of my fundamental problems with EE and Drupal. I'm not suggesting it should be a problem for you or anyone else, but for the sites I develop and the way I develop them, I don't like extra layers of complexity that fall outside the context of the front-end.

Not specific to Symphony, but consider: channels, nodes, taxonomies, categories, sections, entries, resources, and on and on. Taken in the context of the front-end and boiled down to their core, they are all pages or behave like pages. Looking at the big picture, IMO these are all unnecessary complexity and that's why ProcessWire is designed exclusively around pages.

Earlier versions of PW and Dictator have been split out into more layers (not unlike that diagram, and even using some of the terms mentioned above). Over time I've found more benefit to reduction and simplification. Far more benefit than to the occasional and potential flexibility of keeping them separate. if you get deep into the API, you'll even see one hold-out: Fieldgroups (aka sections in Symphony) are separate from Templates in the API, but not from the admin. And that will probably change eventually too as we work to simplify more and more. The goal with PW is not to solve all needs, but to solve most in the simplest way possible.

I like to wander into concept and theory, so please forgive me for straying off topic a bit. It sounds like you are talking specifically about building forms... though I still haven't figured out how to connect that with the diagram. But we don't have a form builder (other than the one used by the admin). The form builder is scheduled for version 2.3 of ProcessWire. So this type of feature is on the roadmap, but multi-language functions are coming first. The form builder is not next on the priority list only because it's not something that necessarily provides more flexibility, just saves time (i.e. you can implement forms of equal flexibility and power without a form builder). The challenge will be to do all this while continuing to make the system simpler, and we'll get there.

[apeisa]

Well said Ryan. I think that simplicity is also the main reason why I felt home right away when I tried pw for the first time.

I think that there is few "simplifications" which really makes pw joy to work with:

a) Urls come from pages: and you cannot break that (but you can easily fetch data from other pages)

b) All markup comes from template: no system generated content (try removing jQuery from drupal site...)

c) Everything are just pages.

Of course there is lot's of other stuff that makes pw so good: it has great API, it's polished, well documented, easy-to-use, modular, oo, easy to extend... but probably most of these aspects come from the fact, that there are these simplifications behind, so there is not so much to polish, document and create UI:s.

About terminology: only thing to consider, is that it is easy to mix template (as a content type, managed through admin) and template file (php file that generates the site markup). I always stumble when I am telling people who are new to pw how this stuff works: "you first create the template and define the fields. Then you edit that template file and add the markup you want." (That is confusing, template is file, or template is content type?)

[ryan]

Thanks for the kind feedback.

I know what you mean about the terminology for templates. A template might be described as a page type (or content type) in other CMS projects. Despite the literal definition, the word 'template' can evoke a file rather than a type. I think this is because of the way the term is used in other CMSs. But in PW, the file is just a component of the template. It's an important connection, but one that I get tripped up on wording sometimes too. Maybe the best way to describe it as the "template's file", clarifying that the file is owned by the template. I would refer to it as an "output file" or a "view", except that they are not always accurate… Your template's file might just as easily be a controller that's calling upon other views. I guess it just depends how you are using PW, and there are plusses and minuses to not being too specific with the terminology. Perhaps we will come up with some better terminology at some point, so lets keep thinking.

[diogo]

I guess i didn't explain very well my point i think because of my inexperience with designing websites and using cms's in particular.

Apeisa, for what i've seen we really can't compare drupal and Symphony in terms of simplicity and control. In Symphony you never have to think how you can remove something, you always have to think how to had it instead. It's core it's also very small and only few extensions are active by default. This is why I think we can compare it with Processwire although they are so different in other things. I won't try to explain how Symphony works because I will be unsuccessful again for sure. But maybe I can tease you both to study it a bit, and discover how it has some really nice things that could give ideas to make Processwire even better.

Ryan, maybe you got it right about the forms, although I was not talking only about them. One of my concerns is how the editor will interact with the back end... and, while the tree view is perfect for building the website, I think it would be nice to be able to organize the the content for the editor. I mean, some people could see everything, others only some pages, while others would land directly on the new blog post page (like in textpattern, for instance).

Since I also referenced the debug tool in Symphony, I was also thinking how Processwire could have something similar (an idea for a module maybe). In symphony, if you add '?debug' at the end of any URL it shows you all the XML data that you can access from that page, and it let's you try XPATH expressions highlighting the nodes that you reach with them. I can imagine that in Processwire we could have all the results of each field shown, and an imput field where we could write some variables and have the generated results.

Hm... this discussion went quite far away from the Breadcrumbs subject. Sorry for that.

[ryan]

There are positives with every CMS project and things to learn. There is no one-true way to approach things. Instead it's just a matter of different CMSs meeting different people's needs and preferences. My relatively brief experience with Symphony left me feeling that it was very much in opposition to how I work. But I have no doubt there are also good points and ideas to learn from, as there are with many products. I try to spend a good deal of time experimenting with other CMSs and will be sure to give Symphony more time based on your suggestion.

In terms of organizing content for an editor with some form of limited access (as opposed to a superuser), I would suggest experimenting with ProcessWire 2.1 rather than 2.0. I think that 2.1 represents a stronger system for working with access to specific types of content. You define the access with the template rather than the page in PW 2.1. My opinion is that the tree view is the right approach whether you have access to all the branches in the tree or not. It is consistent and representative of the site's front-end structure. On large sites, confusion arises when you start pulling things out of the context of the site's structure (at least, that's my experience). You actually have quite a lot of flexibility in defining how this tree works in 2.1, including the ability to specify what fields appear in it on a template-by-template basis. But the desire to display pages in an alternate way in the admin has come up before, so you'll also be glad to know the new page search module can be used as a page listing filter (enabling nearly any kind of page listing display), and we'll be taking this utility a lot further as we move forward in PW development. But the tree structure will always be PW's native view into your site... we'll just provide more options for those that want it.

The debug tool sounds interesting. I wouldn't want to take the approach of intercepting GET vars or making PW produce output directly in that manner, because PW promises not to take that control from your template. But you can achieve a similar type of result pretty easily just by adding a little code to your template's file. For example:

<?php

if($input->get->debug && !$user->isGuest()) {
    echo $page->renderFields(); 
    // uses the MarkupPageFields core module
    // or iterate through the page's fields on your own to produce JSON, XML, etc. 
    return;
}
    
// otherwise render regular page output

[diogo]

Thanks for the kind answer Ryan! I will try your suggestions.

[diogo]

I was trying the user access on 2.1. I really like it, and think it can do everything I wanted. There is one thing that is puzzling my mind, however.

I created a hypothetical situation to explain this: I have a page named "projects" with a template with the same name that i don't want the user to edit, or move, but i want him to be able to create children for it (using the template "project") and to be able to edit and sort them. The problem is that the user is able to move the pages to another parent, but not move them among siblings (because i'm not allowing him to edit "projects" itself). I don't know how this could be solved... maybe by being able to choose, not only wich roles, but also wich permissions for each role on any template... i don't know, maybe it would add to much complexity...

There's also a weird thing happening. Although i don't allow creating new children for the template "project", it's possible to create them by dragging the pages there (like on the screenshot). This is not the intended behavior, is it?

I'm also working on the debugging tool, and i think it can be very useful. Maybe I will be able to make an extension for it

[ryan]

The problem is that the user is able to move the pages to another parent, but not move them among siblings (because i'm not allowing him to edit "projects" itself).

Technically these are two different actions. Moving among siblings is what the 'page-sort' permission refers to. Moving to other parents is what the 'move pages (change parent)' permission refers to. If you have one or the other, PW should let you drag the pages around in the PageList wherever you want. But it won't actually perform the move/sort unless you have access to do it (if you don't have access, you should get a javascript alert after you try). The reason for this is that I don't have PW communicating the permissions to javascript, but probably will eventually just to clarify where you can and can't move a page. The current outcome is that it may appear that you've moved a page even when the system didn't actually do it (due to lack of permission). Though you should get a javascript alert if that were the case.

I don't know how this could be solved... maybe by being able to choose, not only wish roles, but also wish permissions for each role on any template... i don't know, maybe it would add to much complexity...

You could solve it by creating two roles. One that provides just the sort capability (to be added to your 'projects' template), and the other that provides the edit capability (to be added to your 'project' template). Then give both of those roles to the user.

Still, creating two roles for the above scenario is more work than I want people to have to do. So you'll see that's why PW lets you define what roles can add pages below a given template (rather than the separate and deprecated page-add permission, which would have required two roles: one for page-add and another for page-edit). What I'll probably do is setup the permissions so that if you have access to add children below a given parent, and you have page-sort permission, then it'll let you sort the siblings. I think that would make the most sense, and be an expected behavior. I've not worked out all the scenarios, which is one reason why 2.1 is still in beta (even though I consider it stable otherwise). Feedback is much appreciated in this area, as we're in uncharted territory with some of this stuff. I just want to make sure it's as simple and clear as possible.

There's also a weird thing happening. Although i don't allow creating new children for the template "project", it's possible to create them by dragging the pages there (like on the screenshot). This is not the intended behavior, is it?

You are right that's not the intended behavior. PW will let you drag it wherever in javascript, but did it actually perform the move in the system? (like after reloading). If so, it's a bug. Actually I think I spotted where it is.

/wire/modules/Process/ProcessPageSort.module, line 87:

if(!$this->user->hasPermission('page-add', $parent)) 
    throw new WirePermissionException("You do not have permission to move pages to parent {$parent->path}");

Should be:

if(!$parent->addable())   
    throw new WirePermissionException("You do not have permission to move pages to parent {$parent->path}");

I've updated my source and will push to GitHub, but just wanted to make sure this is consistent with the problem you were running into. Because technically, this was still using the deprecated 'page-add' permission, which should have prevented you from being able to move-to-add-children for any users other than superuser (unless you assigned 'page-add' to a role shared by the user and parent's template). That page-add permission is still in 2.1's DB, but it's no longer needed so I'm going to be removing it completely in one of the next updates. Anyway, it seems to me like this bug should have prevented moving of any page for non-superusers rather than the behavior you described, so I'm just wondering if you have page-add permission assigned to any of your roles? If so, remove it (no need for it anymore). If you have time, please let me know what you find.

Interested to hear more about your debugging tool!

Thanks,

Ryan

[diogo]

I'm always amazed on how quickly you answer to the questions on the forum! Makes me believe Processwire will grow fast and well

I can't check it now, but I will come back to it later. I can also put some screenshots of what I already have for the debugging tool.

Thanks

[jbroussia]

He's not only quick to answer, he is also clear, didactic and informative.

I don't have time to play with PW currently, but I'm always reading new posts just because the answers are always interesting. 

[diogo]

Jbroussia, you told it better than me

Ryan,

I solved my issue by applying the two roles (it didn't even occurred to me, and it was an obvious solution), but I confess it was quite confusing because I still don't understand very well how the "sort" and "move" permissions are working together. For what I understood "sort" only works when "move" is also allowed. I think the best thing would be to make these permissions independent of each other. If you allow "sort" but not "move", why not keep the move handle on, and give a javascript alert when dropping it on another parent? (in general, i would even prefer not allowing the dropping at all, instead of the alert)

Concerning the bug: I'm not on the same computer, and on this installation I don't have the same problem, although I did have page-add permission added to the roles I am using... strange... I will check on the other one tomorrow and see if the fix works.

While making these tests, there where two things that annoyed me:

The first one was, when logged as "writer" having some pages on the tree with "edit | view | new | move", others with "new | move", others only with "view"... was visually confusing. I would keep them all in place and make it obvious wich are those that don't work (changing the color, for instance).

The other one was having to go back to the tree after creating a page to create another similar one. Maybe there could be a "create another one" button after saving a page that would immediately create a sibling page with the same template. A good place would be the notifications area. Something like this:   "page /path/to/the/page/ published. You want to create another one?"

--------------------------

The debugging tool is just a rough draft for now

For now, I only applied this code to the header include, partially based on the code you gave me before, and styled it a little. The idea would be to turn it into a module instead:

<?php if($input->get->debug && !$user->isGuest()) { ?>
<div id="debug-tool">
<div id="input">
	<form action="#" method="get">
	<input type="text" name="debug" />
	</form>
</div>
<ul id="page-info">
	<li>template: <?=$page->template?> </li>
	<li>name: <?=$page->name?> </li>
	<li>path: <?=$page->path?> </li>
	<li>children: <?=$page->numChildren?> </li>
</ul>
<ul id="page-fields">
	<?php
	foreach($page->fields as $field)
	echo "<li><strong>&#36;page->" . $field->name . "</strong> " . $page->$field . "</li>";
	?>
</ul>
</div>

I am dividing the tool in 3 areas: one for basic info about the page, one other for throwing all the fields available for the page, and an input field on the top for inserting other variables (there would be an output for them under it, but i still don't know how to do this).

[ryan]

For what I understood "sort" only works when "move" is also allowed.

This should not be the case. One can sort without moving. But please let me know if you find otherwise. Note that PW's PageList uses the "move" label to refer to both. As long as you don't change the parent, your "move" is considered a sort, behind the scenes. Once you change parent (i.e. drag to another branch), it's considered a "move" behind the scenes. And that's also how PW determines what permission to check. So using the term "move" is just to maintain simplicity at the UI level. I thought separate "move" and "sort" links would be confusing at this level.

I think the best thing would be to make these permissions independent of each other. If you allow "sort" but not "move", why not keep the move handle on, and give a javascript alert when dropping it on another parent? (in general, i would even prefer not allowing the dropping at all, instead of the alert)

What you are describing should be the current behavior (at least, that is what's intended). It sounds like it didn't behave that way in your instance? If so, let me know how to reproduce. Here is the current logic that determines whether it's going to show a "move" link (whether that means sorting or changing parent):

<?php
if($page->moveable() || ($page->sortable() && $page->sortfield == 'sort')) {
   // show the 'move' link in the PageList
}

And here's how it determines what to do after you dragged a page. It will attempt both move and sort, but you can see it won't attempt the 'move' if the parent wasn't changed:

<?php
if($page->parent-> !== $newParent) {
    // user moved the page to another parent
    if($user->hasPermission('page-move', $page) && $user->hasPermission('page-add', $newParent)) { 
        // user has access to to move the page to the new parent
    }
}

if($user->hasPermission('page-sort', $page->parent)) {
    // user has permission to sort this page and it's siblings
    // but we need to make sure this parent has children that aren't already presorted.
    if($page->parent->sortfield == 'sort') {  
        // these children are not presorted
        // user can save the new order they dragged to 
    }
}

When you edit a page with children, you'll see on it's children tab that it has a field where you can select an automatic sorting order. This is where $page->sortfield is set. If it's set to "sort" (the default value, aka no value selected) that means you can drag to sort them in any order. But if it's set to some other field, then you won't be able to drag to sort because it would violate the preset order. For instance, if you had a page of news items sorting by date, you wouldn't want users moving stuff out of that order. So this preset sortfield on the parent takes precedence even if you have page-sort access. You can see that in the code above.

It's also worth nothing that "page-sort" permission needs to be assigned to the parent whereas "page-move" is assigned to the child. Since sorting a single page can feasibly affect the order of all siblings, I thought this permission belonged with the parent. Otherwise PW would need to check all the child pages for "page-sort" permission before you could sort any one of them... and that could lead to real confusion when one of the siblings was not like the others. But perhaps "page-sort" would more accurately be termed "page-sort-children".

The first one was, when logged as "writer" having some pages on the tree with "edit | view | new | move", others with "new | move", others only with "view"... was visually confusing. I would keep them all in place and make it obvious wich are those that don't work (changing the color, for instance).

I think that makes sense. Though the intention with these links is that they will be pluggable (like anything else in PW), and modules can add additional links here if the given page calls for it. So it's feasible down the road that there might be a dozen possibilities of what links appear there, and I think that might be a lot to look at. But that's not the case now, so I will look at this more closely and experiment with it.

The other one was having to go back to the tree after creating a page to create another similar one. Maybe there could be a "create another one" button after saving a page that would immediately create a sibling page with the same template. A good place would be the notifications area. Something like this:  "page /path/to/the/page/ published. You want to create another one?"

I like your idea of an "create another one?" in the save notification, and will look at adding this. Also wanted to mention a time saving tip for when you have to add lots of pages. After adding your page (and publishing it if necessary) click the breadcrumb trail at the top for the parent. It should take you to the page list with that parent opened and a "new" link right there waiting for you to add another. Not quite as simple as the idea you mentioned, but still useful when adding lots of pages. Btw, 2.1 does this, but 2.0 doesn't (though Adam wrote a plugin that will do it in 2.0 among other things).

Your debugging tool is really looking good–please keep us up to date. And you mentioned some stuff that you didn't yet know how to do, but I wasn't clear about what that was–please post questions any time. Also, if you are interested, I can show you how to develop this as a module so that you don't even have to put this in your templates (the module can slip it in there at page render time, in any template's output).

[diogo]

Hi!

Sorry for the late answer... and it won't be very complete one because i've been busy with other stuff.

Concerning the "bug":

I did try it on the installation where i had the problem, and i was able to drag them inside links that don't allow children, but not always, it allowed me to do it only twice (not only javascript, the system really accepted the change). Is this possible? Anyway, it didn't happen anymore after I applied the changes from github.

But perhaps "page-sort" would more accurately be termed "page-sort-children". 

On the sort/move issue, there was some dumbness from my part. I confess I didn't realizes that "sort" refers to the children, and, consequently, it must be applied to to the parent page. Considering a rough (and abusive) estimate of 20% of users that may be as dumb as i was i would say that this would be a good solution.

Your debugging tool is really looking good–please keep us up to date. And you mentioned some stuff that you didn't yet know how to do, but I wasn't clear about what that was–please post questions any time. Also, if you are interested, I can show you how to develop this as a module so that you don't even have to put this in your templates (the module can slip it in there at page render time, in any template's output). 

I haven't had any time to work on this. I did try to make a module, base on the discussion you had on Apeisa's Admin toolbar module. But since I was having some problems to make it work, I decided to start hardcoding the tool on the header, and apply this later. Your help will be very welcomed!

The stuff I don't know how to do, is mainly, to accept the variables on the imput area, and render the result on the output. I can imagine it's not easy to implement it without safety constrains... but i really don't know. The idea would be to show the user the main variables of the page he is in, but also allow him to test any other variable that he can reach from that same page.

Another thing. Since I last updated my dev version of chrome, the processwire website is looking like on the screenshot attached. In Firefox and Opera, everything is fine. Should be some problem with this chrome version css implementation, but i wanted you to know.

[ryan]

Sorry somehow I missed your reply before. I need to make those pagination numbers bigger.

I'm going to update the label for the page-sort permission to indicate that it's specific to sorting the page's children. Thanks for bringing this to my attention, I think this will help to reduce confusion in the future.

I'll be glad to help you in any way I can with your debugging tool. Feel free to post questions or code in the Modules forum (or wherever you prefer), and I think we can help you get your debugging tool doing whatever you'd like. I don't see a problem with accepting input in the way you'd indicated, though you are right that we will have to make sure we're covered on the security side.

I've not been able to reproduce the output from your screenshot in the latest version of Chrome. Does it still do that for you? I'm using Chrome 12.0.742.112 in OS X (their version numbers sure look like IP addresses). If you are still seeing that error, can you post the Chrome version number and platform you are running on?

Thanks,

Ryan

[diogo]

Thanks Ryan, as soon as i start working on it again, I will open a new thread in the modules forum to ask you some questions, and also to get some ideas.

As I told before, I'm using a dev version of chrome (14.0.803.0 dev on linux), so, it's probably some bug from the browser.

thanks,

Diogo

[onjegolders]

Sorry Ryan, perhaps a dumb PHP question, in your template example, what's the easiest way to remove the last > from the breadcrumbs?

[Soma]

You can try something like this:

$parents = $page->parents->slice(2);
foreach($parents as $parent) {
echo "<li><a href='{$parent->url}'>{$parent->title}</a>";
// only output ">" if not the last entry
echo $parent->id != $parents->last()->id ? " > " : "";
echo "</li>";
}

[onjegolders]

Thanks Soma, I ended up setting a count variable and a total variable and matching the two.

[ryan]

Another way to do it, just using PHP string functions:

$out = "<ul>";
foreach($parents as $parent) {
   $out .= "<li><a href='{$parent->url}'>{$parent->title}</a></li>!";
}
$out = str_replace('</li>!', '></li>', rtrim($out, '!')) . '</ul>';

[OrganizedFellow]

Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through:

<?php
foreach($page->parents()->append($page) as $parent) {
    echo "<a href='{$parent->url}'>{$parent->title}</a> ";
}

Hi Ryan.

I'm using the above and can't figure out how to style the current page.

<ul class="breadcrumbs">
	<li><a href="#">Home</a></li>
	<li><a href="#">Page1</a></li>
	<li><a href="#">Page2</a></li>
	<li class="current"><a href="#">Page3</a></li>
</ul>

How would I style the current page?

This is what I have right now:

echo "<ul class=\"breadcrumbs\">";
foreach($page->parents() ->append($page) as $parent)
	echo "<li><a href='{$parent->url}'>{$parent->title}</a></li>";

echo "</ul>";

Edited March 6, 2013 by OrganizedFellow

[MichaMichaMicha]

Hi Ryan.

I'm using the above and can't figure out how to style the current page.

<ul class="breadcrumbs">
	<li><a href="#">Home</a></li>
	<li><a href="#">Page1</a></li>
	<li><a href="#">Page2</a></li>
	<li class="current"><a href="#">Page3</a></li>
</ul>

How would I style the current page?

This is what I have right now:

echo "<ul class=\"breadcrumbs\">";
foreach($page->parents() ->append($page) as $parent)
	echo "<li><a href='{$parent->url}'>{$parent->title}</a></li>";

echo "</ul>";

echo "<ul class=\"breadcrumbs\">";
foreach($page->parents() ->append($page) as $parent)
	echo "<li".($parent == $page?" class='current'":"")."><a href='{$parent->url}'>{$parent->title}</a></li>";

echo "</ul>";

This should do the trick, if that's what you're looking for.

Note: not tested for syntax-errors, typed it directly in the commentarea.