This module is awesome in how it manages the process. I am using organic groups and it is saving me a lot of time.

The one problem that I have is it not authenticating the block access on the URL which is a problem.

I have certain blocks that are only available through certain paths and when I use this to alter the path, the block doesnt show.

Any ideas?

Comments

chrispeat’s picture

chrispeat CreditAttribution: chrispeat commented

Just to report back, I couldnt ever figure this out and had to remove blocks from organic group forums. Bit weird really but sure its a n00bie problem...

..if anyone figures it and see's this post it's be great to know!

:)

luke.oakes’s picture

luke.oakes CreditAttribution: luke.oakes commented

Hi I'm having the same problem. Want to show a block on an ..../edit page, but can't do so using the alias.

I'll have to work around this by not having a block on the edit page, but including it in the content type help text... which isn't ideal but I'll get over it =)

Is it fixable?

(Great module though - I hate seeing node numbers in the urls!)

alexmartin’s picture

alexmartin CreditAttribution: alexmartin commented

Hi,

I'd love to get this working too, as was hoping this module would allow me to display blocks on edit pages. If there's any alternative methods out there for achieving this I'd love to hear about it.

Other than that, nice module, so many thanks!

bropp’s picture

bropp CreditAttribution: bropp commented

I would also love to have this functionality.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Status: Active » Postponed (maintainer needs more info)

I need more details on what steps I should take to reproduce the condition everyone wants here.

kurkuma’s picture

kurkuma CreditAttribution: kurkuma commented

Just enable the module and try to restrict the visibility of any block to a path by its alias. If the alias is related to "subpath url aliases" the visibility conditions will not work. It seems it has to do with the way Drupal works with aliases, which are complete strings.

process91’s picture

process91 CreditAttribution: process91 commented

I had this problem as well. Just to clarify, here's the issue:

Node has internal path of "node/1" and has an alias such as "content/BLAH"
This module makes it so that "content/BLAH/bunch-of-args" still redirects to "node/1/bunch-of-args", for example "content/BLAH/edit" will now show the edit page "node/1/edit". However, if we had blocks set to visible on "content/BLAH/edit", they do not show up.

Workaround: set the block's visibility to "node/1/edit". If you were attempting to make the block visible on all node edit pages, you could do this: "node/*/edit". Other wildcard configurations are similarly applicable.

I would guess that the subpath alias module (or perhaps the urlalias module) changes the Drupal's internal path, and it does so before blocks are rendered.

DaPooch’s picture

DaPooch CreditAttribution: DaPooch commented

I'm having the same problem. Any subpath alias now doesn't respect the wildcard visibility rules for blocks. I need the subpath to still show the appropriate blocks assigned to it. It would be nice not to have the path be node based as indicated above since node id's change from dev to production versions of the site and it would be one more thing to have to change during deployment.