Panels, Views and SEO

The path module just creates URL Alias. Internal are always the same urls. Views and Panels registers internal menu items.

But what can do panels/views here, as you say there should be a module which handles per path, and views and panels does not own all paths!

I think the problem is that you're conflating aliases with system paths. They're simply not the same thing.

The path module creates an alias from one path (content/stories/read-my-blog) which leads to the real path (node/271)

Internally, Drupal still sees this as node/271 and all the path.module is doing is filling in the url_alias table. It doesn't let you create the same path twice, so it prevents you.

But there are LOTS of system paths in Drupal and most of them aren't aliases. Try enabling forum module, then adding aliases that happen to match the forum paths you can use. You'll see the same problem. The issue is that when you add an alias to an existing node, you're not "creating a path", you're aliasing an existing path. This is very different, from the perspective of the software.

I'll address the rest of the SEO stuff at a later time. I understand your basic points, but what you're asking isn't really to address with Drupal not really having a centralized API for doing this kind of thing.

Subscribing...

Well, panel nodes are just nodes like any other, only you can attach a layout to them. They're not special in any way, and in fact compared to other panel pages they're crippled. I don't tend to think to much about them; they only exist because in some people's workflow they need that, but I don't personally find them very useful.

Panel pages are intended for public consumption, and they're often meant to be used to provide the primary structure of a site. They use the normal drupal hook_menu() system for defining, such as all paths in the admin/* tree, forum, blog, etc. They definitely aren't aliases.

To be honest, I have no idea what 'path search' you refer to. I'm not familiar with a path search in Drupal, beyond the alias filter at admin/build/path but looking at it, I see that it is pretty specific that it's an alias filter, not a path search. So I'm not sure what you're referring to at this point.

Here one can find system paths and aliases for all varieties of publicly displayed Drupal pages... taxonomies, nodes, paths to various system functions, you name it. If I want the user login page to be on /12xu instead of /user I can do that too.

Hm.
And if you want the /node/17 to have the alias /user you can do that too!
This is an interesting observation - it illustrates the general case 'problem'. As Merlin says in #3, aliases are not system path. Panels makes genuine system paths - so they do not appear in the aliases table. This is a bigger deal than just panels.

It could be that path.module itself should warn when creating an alias that will conflict with an existing system path ( alias /node/7 to 'admin' and see what happens ) but that's therefore a wider issue. I actually like this effect, and I'm sure we've taken advantage of it before now, so would vote to leave it in as a quirky feature.

It's also an interesting feature request that non-node pages could/should have their own meta-descriptions and page-titles. It's a valid request, although clearly not one with a high priority for the developers. I assume you could have the same complaint about views, taxonomy/term/n pages, user profiles etc.
This again points to a larger case solution that could be applied globally for SEO fans, rather than an exception/feature that must be added to everyones modules. I imagine page_title and Meta Tags are the ones that should be expanded to add the ability to add meta-features to any arbitrary URL. I can imagine them doing it, although it would require a new UI.

.dan.

I would be more than willing to have both Panels and Views support a good API for dealing with the meta tag. Doing it individually in each app is troublesome, however.

Also, greencrescent, you're still wrong. When I visit admin/build/path the search box is labelled "Filter aliases", not "Filter path".

Hi,
There was a Panels1 metatags integration. It would be great to ask if the curent version of metatags could again support the current (3th) version of panels pages!
Green Crescent please take the challenge to get this rocking for panels 3, fling issue on www.drupal.org/project/nodewords and subsidairy modules with nodewords and monitor and help in this.
Greetings, Martijn

Technically the support should be for the page task in delegator module.

I subscribe to the new modules queue and just saw SEO Friend come up. It mentions the existence of nodewords_bypath - which I'd not seen before.
I'd suggest looking at that. If it works, it would solve the general case for you. There may still be some tie-in with views/panels possible (a UI button or FAPI option) but it's not really views or panels job to add this feature.

I am leaving this open in that I will consider patches to make it easier for Panels to integrate with modules that provide meta tags, but I am not going to do anything specific because it seems like a more universal solution is better.

Thanks for leaving this open for potential patches, Earl. I resisted using panels (stubborn old-fashioned hand-coder) and then, took the plunge for landing pages. Boy, what a mistake being stubborn is. You do good work, Earl. This is one of those modules that changes people's lives and you should be proud. The meta tags. Yes. That's a stumbler for me, too, as I now consider converting several of my commercial sites to Drupal. Mentally my workaround is to not use panels for the home/front page and only for landing pages, which will take the hit, but I think I can survive. Just writing to say thanks for being open to this issue, Earl. It's an important one.

Hopefully the end result is that a good meta tags solution will be done that Panels, or rather Page Manager can work with, and then everyone will win.

This is no longer a problem for me - I solved it by learning to use panels better...

When using panels node template, all the useful SEO stuff comes from the node, so you can use page title and nodewords coupled with panels excellent layout features...But when using 'panel pages' you cannot add in this extra data...

This seems to be the issue here - for someone only using panel pages to write their content, this is a big issue because there is nowhere to input their meta data etc, but for someone using panels to create templates to display nodes, this really isnt an issue because everything is carried accross from the node including all nodewords and page title data.

For SEO minded people, the best way to use panels is to use the node template/tax template features and set up variants for different content types and selection rules. This is a much more dynamic way of using panels, and also avoids the duplicate content you get when you insert a node into a panel page.

All the best, joe

Still active. I definitely see where this is a hole that needs to be filled.

Hi current nodewords 1.12beta holds nodewords_bypath AND token usage per contenttype
May be token usage can be used for a ctools/pages nodewords framework integration like the per contenttype usage?
Greetings, Martijn

Hi current nodewords 1.12beta holds nodewords_bypath AND token usage per contenttype

Nodewords doesn't come with nodewords_bypath.module, that is part of a different project. Also, latest versions of Nodewords includes already the functionality present in nodewords_bypath.module. You should not be using nodewords.module together with nodewords_bypath.module; if you would do that, then nodewords.module emits an error message at /admin/reports/status.

Nodewords can add meta tags to any pages, given you provide a URL. It doesn't actually assign meta tags to anything that is part of a page.
As panels and views normally have a URL associated with them, you can already assign them meta tags; if they don't have a URL associated, then they are included in a page, and you should use the page URL.

subscribing

If anyone is using Panels node templates then there is currently a solution to auto generate Meta Tags, providing the page is configured correctly. See this issue for detail http://drupal.org/node/673080. This solution works with Integrated Metatags, and may also work for Nodewords (untested).

I can also confirm that Page Title module works fine for Panels node templates.

For non-node template panel pages then, as kiamlaluno mentions, Nodewords enables adding custom metatags by URL path. Together these methods should enable you to control title/ metatags for your Panel pages. Although I agree that ideally, the functionality would be a bit more seamless.

Hi Daniel,

An interesting approach. It would be great if metatags became a sort of ctools context which would be used in de ctools gui.
greetings, Martijn

One update that may be *very* relevant to nodewords:

As of CTools 1.6 (I think), Page Manager can now have tabs added to the operations list by other modules. Doing so is not *completely* straightforward, but if you look at Panels Everywhere, it adds an operation to variants for choosing the 'template'.

Nodewords could do the exact same thing to add a tab for its meta data. Doing so would solve a whole lot of problems, I think.

Would nodewords still be responsible for storing the data it exposes on a tab or does Panels/Ctools do that automatically? If it's the former would panel/variant map to entity/bundle? Please feel free to respond to http://drupal.org/node/864386#comment-3391356 where we're planning the meta tag schema and architecture.

Tagging...

If you want, nodewords could stick it in $handler->conf, as long as it used a namespaced key and store data per variant.

There is no guaranteed storage at the 'page' level so you have to do it per variant unfortunately. This has frustrated me more than once, but system pages such as node_view have no actual storage of their own. Custom pages do, though, so if you're willing to detect what type of task it is, you could do page level node words.

I suspect just storing it on the $handler is good enough.

Nodewords could then do all of its magic through hook_ctools_render_alter() which will be passed the handler that is being rendered and all the actual output.

BTW the actual hook to add a tab (called an operation, internally) is hook_page_manager_variant_operations_alter()

You can attach either a single form or multiple forms to this.

At this point I have no idea how panels will map to entities or bundles. I'm not sure that they will in D7, but that's something we'll figure out more at the code sprint.

Well at this point I'd just need to know if we can somehow store panel meta tags in a fake entity/bundle relationship where entity = 'Panel/Page', bundle = Panel name, and {metatags_data} stores entity = 'Panel/Page' and ID = name of variant or specific display. I think I'll need to play more with Page Manager and Panels to see if it could hack into this architecture.

One issue is that if you store the data separately, it will not export along with the page, which could be a problem on a site using exports for deployment.

True. Ideally we'd want to store this data along with the page itself and not use the metatag module storage. I'll have to play and inspect how things work in the db to figure out what's possible or not.

$handler->conf is a serialized array, so you can put pretty much whatever you want in it. $handler->conf['metatags'] = array('everything', 'it', 'needs');

Out of curiosity, is there a way to access the panel "Administrative description" from a token? Kind of like how a taxonomy term description can be a token. I could use that as a description meta tag for the page. Right now I have to set up custom page nodewords for all my panel pages.

I'm not sure if this has been covered allready, but to get custom page title / meta tags for panels layouts, I used these modules:

page title
nodewords
nodewords_page_title

Then after setup you can specify custom pages paths, and change their page title, meta tags etc:
admin/content/nodewords/custom

The only thing is out of the box there are no taxonomy tokens available, these guys figured it out though:
http://drupal.org/node/837114

Hope this helps someone.

Yup, I am one of these guys, this method is working great!
You need to add some argument-tokens and then it is a lot more friendly!
greetings,
Martijn

To minimize SEO duplicate issues I've added this line on my robots.txt: Disallow: /norobot/
Each time I use a node designed to be used in a panel, I override his path with /norobot/nameofthenode

However, what I can't figure out at this point is how to avoid the node to be included in search results.
I need to publish the node if it had to be visible on the panel...
Any thoughts ?

Apologies, I may be missing the point in this thread.

Here's how I've made Panel Content Type searchable internally that seems to work well. Includes, Custom Search, Display Suite, Views, XML Sitemap. Additionally, if assign all content types to using Menu Force so that there is an obvious structure in a Primary Menu, although can get large, it resolves some things including breadcrumbing. Crumbs module has been of great assistance in combination with URL Alias module to set content type Pattern Paths (some content don't need paths like those for collection of lots of data, but the presentation can be in tables on a searchable panel). Since search is ultimately about the content and not the means by which to create a facade for content...

• Index Panel Content Type for search
• Don't index basic page content type (or any content type you want really)
• Add a node reference (ex: Select Teaser) field to Panel Content Type
• Manage Display settings for Panel Content Type and hide field (Select Teaser)
• Give roles perms to manage that content type for leading text, summary or whatever text content to provide context for the page, and the panel panes that are added with views, blocks, etc.
• Add that node to the Panel (existing node).
• You can then allow and show content contributors to use contextual links in Panels, maintaining some control since they can only edit the Basic Page content type.

With the advancement of D6 modules (and the discontinuation of D6), I think this works as it should.