Using hook_ctools_content_subtype_alter(), or in the case of blocks, hook_ctools_block_info(), to alter the "render last" behavior has no effect since it is only run on rendering, and not during the prepare step.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Status: Active » Needs review
FileSize
673 bytes

See attached.

tim.plunkett’s picture

The first thing ctools_content_get_subtype() does is call ctools_get_content_type(), and then it goes on to call all of the rest of the hooks and alters.

larowlan’s picture

Status: Needs review » Reviewed & tested by the community

Works for me
Allows facet api blocks to appear above search api search results.
tim.plunkett++

setvik’s picture

works here as well

nbucknor’s picture

works for me too

acrollet’s picture

Status: Reviewed & tested by the community » Needs work

This patch meets the intended purpose, however it breaks the render order for at least the node edit general form plugin. Looking to see if I can find a resolution.

acrollet’s picture

Status: Needs work » Needs review
FileSize
977 bytes

Attaching a patch that follows the approach in #1, but only when the pane type and subtype don't match, on the theory that hook_ctools_content_subtype_alter() and hook_ctools_block_info() will only be used when there is a specific subtype. I don't know if this theory is valid, so it needs review from someone more intimately familiar with the whole system. I do know that this patch works for the use case of needing the facetapi blocks to render last on display, (ref: #1669918: Allow Panels to properly use Facet API blocks) without hosing the node edit general form. In my limited testing thus far, this approach does not appear to break anything else.

Side note: to reproduce the problem with the node general form, apply the patch in #1 and use page manager to override the node edit form. Place the general form element first, and a field (e.g. body, tags) after it. The general form will not be rendered last as it should, leading to a notice about the field element not existing in the form array, and the edit panel will not be displayed as expected.

tim.plunkett’s picture

Oh, this makes a lot more sense.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed #7.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kopeboy’s picture

Issue summary: View changes

Is this included in a stable release too?

(I cannot get Facets to work with Panels when using a Search API View Content Pane with contextual filter

kopeboy’s picture

Version: 7.x-3.x-dev » 7.x-3.4
Status: Closed (fixed) » Needs review

The last submitted patch, 1: panels-1669908-1.patch, failed testing.

Status: Needs review » Needs work
acrollet’s picture

Version: 7.x-3.4 » 7.x-3.x-dev
Status: Needs work » Fixed

This code was committed 2 years ago, and 1.4 was released this year. Please search for help in forums/IRC/stackexchange, or at worst open a support request rather than re-opening old fixed issues.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.