Allow setting block weight via context admin UI

Currently the easiest way to do this is to export both contexts and adjust the weights manually in code. This is obviously not ideal.

One UI concept I would love to do some work on is to be able to edit block visibility/weights "inline" - for example, when viewing a certain page of your site it could be possible to switch to "Edit" mode where the blocks then become draggable/reorderable in their regions. Under this model, we could detect the active contexts and adjust the weights of blocks from those contexts on the given page accordingly.

A bit of discussion is going on at #549098: Appears to be no way to control weights of blocks in simultaneously active contexts.

Young,

that would be fantastic!

This issue has been addressed in the 3.x branch.

In case anyone else sees this thread and is confused as to exactly how "this issue has been addressed in the 3.x branch" (as I originally was), I think the solution yhahn is referring to is to use the inline editor.

See #772006: Odd behaviour with block order with sub sections in different namespaces.

After searching around a bit I discovered that this same issue seemed to be open across numerous threads, such as:

• #549098: Appears to be no way to control weights of blocks in simultaneously active contexts
• #772006: Odd behaviour with block order with sub sections in different namespaces.
• #842162: Global vs Local Block Ordering in Context UI
• #892430: Cannot set order for one block in Global context and another block in another context

As far as I can tell, this thread is the one that the maintainer has indented to be the central location for the solution (use v3 and the inline editor), so I marked the above threads as duplicates, and pointed them here. I very much hope that was the prudent action.

Furthermore, though this thread currently marked as "closed", it still seems like there is a lot of confusion floating around about this issue (as indicated by the list of issues/thread above), and so I'm humbly changing the status here to "active" once again. I'm also sorry if that's not protocol (please feel free to toggle the status back if necessary) I'm just trying to help make sense out of an array of similar issues.

My justification for changing the status is the following:

1. Though there is a solution available (and rather slick/fantastic one IMHO) it does not seem to be well known or accessible information. Unless I am missing something, it seems like the only documentation of this solution is within these issue threads and possibly some 3rd party screencasts. Perhaps it would be worth adding a note to the readme file or similar? If anyone agrees, I'd be happy to submit a patch with some readme text updates... I'm just not sure if that's the best approach.
2. Some people seem to have issues with the need to install additional/optional modules (admin, jQuery UI) to achieve cross-context block ordering, arguing that it should be core functionality. I'm personally not too opposed to the dependency of additional modules (so long as the solution is clear) but I wanted to note that this seemed to be a common theme in a couple of the threads noted above.
3. From what I have tested, it seems that the ordering set with the inline editor is very difficult to maintain. Once you set ordering for overlapping contexts, any change to one of the involved context settings (related to ordering or not) seems to reset all the ordering settings. This means that one has to navigate back through all their overlapping context and re-apply the ordering (with the inline editor) almost every time the make context setting changes. I can guess why this is (all form processing settings fire when a context is changed regardless of what settings are changed?), but it does seem to be a limiting factor when utilizing the current solution. This is not a major flaw, but I just wanted to point it out.

Anyway, these notes are just my humble attempt to consolidate this issue in one place in hope that it will be useful to other users.

Cheers,
Ryan

The inline editor does not work for ordering multiple contexts. If you have multiple contexts and order one page then visit another and order that one it will continually break / revert the ordering of other blocks. The only definitive solution to this is to either have context obey the order from the block management for conflicting contexts (perhaps optional via settings checkbox) or to provide a default context block order for multiple contexts in the context system (settings) it's self.

Thoughts?

Yeah, jfine, I think you are right. It seems like managing any sufficiently complex case of overlapping contexts is beyond the current capacity of the inline editor (though the inline editor is certainly fantastic for simple-case scenarios without overlap, or only simple overlap).

It seems more and more like exposing some form of "global" ordering option in necessary for some complex cases. This global ordering option would not need to compete or replace the inline editor, but could simply compliment it for those users with complex needs.

There were some comments on this specific idea at #842162: Global vs Local Block Ordering in Context UI, but I think I could summarize them (along with your point above) as:

1. Introduce a separate "global" block ordering tab/pane within each context's block options (that would show all blocks used in each region, across all contexts, with the same drag-and-drop interface). i imagine this would require quite a bit of new UI work, as well as the addition of a new ordering scheme... and could be confusing if local orders conflict with global ordering.
2. Allow users to tap into the global block ordering without needing to use the inline editor or do any round-about import/export tasks with their contexts:

• Expose the numeric order/weight value directly to the user within the block order options. This way they could manually calculate cross-context ordering if needed
• Tap into the core drupal block ordering interface for the global ordering, and perhaps expose a context option to toggle whether-or-not that ordering will be used.

Another idea that is independent of a "global" block order option would be to implement some form of weight to contexts themselves (higher weighted contexts could increase the weight of their blocks when there is overlap). Of course this option would only allow you to re-order groups of blocks, and could be a bit confusing.

Anyway, these are just some thoughts. I imagine some form of #2 in the list above would be easiest to implement, but I think that someone who knows a bit more about what's going on under the hood would need to weigh-in on that.

Ryan

Very nice summary Ryan. The weighting of the context themselves you mentioned also seems like a very interesting option. Hopefully some of the Context devs will join the discussion.

I am trying to determine if I add block A to context X and block B to context Y (both blocks in the same region) and I visit a page where both contexts are active, is there a way to determine which block will appear first? Pretty sure I am referring to the same issue described in this ticket. I just had to type it out to make it clear in my own mind.

Would be very helpful to be able to set weights to blocks that would apply across multiple contexts.

suggestion: add a simple textbox to each context in the content ui page.

that textbox would contain the context weight.
weighting contexts would be a simple fix to re-order contexts and the blocks.
wouldn't cover all the cases though, like cross-ordering blocks from multiple contexts.

it could be further expanded with a behavior similar toDraggable Views.

subscribing

@LPCA: I agree. While not a complete solution, a good starting point might be the ability to weight the contexts as a set as opposed to each block across contexts.

Tracking. I just spent half an hour dragging blocks around and trying to track why my changes weren't being saved, only to discover that block a in context 1 is back where it started after I modify the order of block b in context 2 and block c in context 3.

One thing that has frustrated me is that if I explicitly edit context a and move a block there, it might not change the weight of that block, and instead it changes only the weight of a block in context b even though I was not editing that context. This makes it difficult to get blocks in the right order across multiple pages.

I'm not sure that weighting the contexts is the best solution, if it's a question of either block weights or context weights. (If it's both/and, well and good.)

it's definitely both, but it's not easy to arrange a way of changing both at same time, seemingly.

adding the weight for contexts now (textboxes) would help and maybe could later be expanded in a different UI way...

Well, it seems that the most popular solutions from my list in #9 (so far) are to either create some form of weight system for contexts themselves, or to expose numeric block weights directly to the user. IMHO the latter seems a bit more useful, and possibly easier to implement.

Sooooo, I had a stab at this. Now, I need to add the disclaimer that all the logic and code behind the context module is slightly over my head currently. However, a little digging around, and a whole bunch of trial-and-error seems to have revealed a potential (and simple) way to expose the block weights directly to the user. I've rolled this into the attached patch. I don't think it's up to the standard of a solution just yet, but I was just hoping it might be a catalyst for folks to play with one potential tangible solution.

What I discovered is that the "tabledrag" feature context uses for ordering blocks actually includes a form element for the block weight, but it's hidden with some css. In addition, the weight set via this tabledrag mechanism is not actually saved in the context settings when submitting the context form. Instead it seems like some dynamic javscript/jquery logic is used to re-calculate the order each time the form is submitted... even if no changes were made to the ordering. This explains why any delicate cross-context ordering gets messed-up whenever a context is re-saved. The patch simply exposes the weight form element, and ensures this value is the one that gets saved (and maintained) in the final ordering settings for the context.

This change can be toggled on or off from the context settings (admin/build/context/settings). So people who don't want to mess with manual settings (and prefer the inline editor, etc) can keep the numeric weights hidden.

There are currently some caveats however. If this solution is useful to other people, perhaps others would have some knowledge of how to fix these:

• When you add a new block (with the ajax interface), the weight is not exposed yet, and is set to 'NULL'. You have to save the context before you can set the weight. I think some work on plugins/context_reaction_block.js would be needed to address this.
• The inline editor will overwrite any manual settings (as it still uses the original context weighting logic).

There may be other issues as well. I'm not sure if there are other consequences of changing the way weights are assigned. Still, my minimal testing within one dev site showed useful results.

Hope this helps the cause a bit....

Ryan

Edit: just a permissions issue.

To anyone else testing this patch, note that you will need to go to admin/build/context/settings and check the config box before the feature works. You can then set the weight at admin/build/context/list/my_context/edit by clicking on the block reaction tab and selecting the desired weight for each block.

#17 applied fine for me and allowed me and seems to work as described.

I do think the inline editor's block weighting logic could be improved as well, but this is at least better than editing DB records or exports manually.

Initially the patch failed to apply. I manually adjusted the patch to work with Netbeans, and even then the CSS didn't patch, so I did that manually. Attached is a new patch if anyone has the same trouble.

Now it works perfectly, and my block weighting issue is resolved. Thanks Ryan, much appreciated!

Hi blairski,

To apply the patch did you use patch -p0 < mypatch.patch, and do it relative to the module root (not the plugins directory)?

I too use netbeans, but I have been creating patches directly from the command line. In this case I used diff -urp original_directory new_directory > mypatch.patch, relative to the module root, to diff the entire plugins directory (as per the suggestions in http://drupal.org/patch/create).

It looks like your version is relative to the plugins directory. Perhaps this discrepancy was behind your trouble? If I'm missing something else, someone please let me know. I want to be sure any other patches I make in the future are up to the right standard.

Hummm, it also looks like you were able to make your patch based on a diff in your netbeans local history? I have not figured our how to do that in netbeans 6.8 yet... it will only let me build patches based on snv or cvs diffs. Interesting.

Cheers,
Ryan

If it is of help to anyone, I got around this problem by altering block weights programatically using hook_context_load_alter() (hook defined in the Context API). I set up a small custom module named "context_mods" and called hook_context_load_alter() to change the block weights as needed.

Here's an example from my project (defined in "/sites/all/modules/custom/context_mods/context_mods.module"):

/**
 * Implementation of hook_context_load_alter()
 */
function context_mods_context_load_alter(&$context) {
  // If Context "user_admin" is loaded,
  // change weight of the "Site Admin Menu" block (block id "menu-menu-site-admin")
  } if($context->name == 'user_admin') {
    $context->reactions['block']['blocks']['menu-menu-site-admin']['weight'] = -99;
  }
}

Just tried the above patch and it seems to work thus far.

subscribing

Just a note on how I have been using the patch from #17...

When setting up a new site, or making notable info architecture changes, I've found that the inline editor is still the way to go (as you can add/remove blocks directly and quickly with the inline editor). Once things are mostly in place (and mostly ordered) it's just a matter of "tweaking" the cases where contexts overlap and place blocks in common regions. For this I turn to the context UI and manually adjust the numeric ordering for a few blocks (via the functionality provided by the patch), and from that point forward I pretty much stop using the inline editor altogether. This has been working well for me so far.

So I don't think this patch permanently compensates for the shortcomings of the inline editor, but it has proven to be very useful. Given that one can toggle this functionality on or off (I think it only applies to a subset of users), perhaps it is a nice short-term fix until the inline editor can be enhanced a bit.

It would still be nice to see functionality within the inline editor become the ultimate solution. I'd love to be able to show clients how to use the inline editor as they would be quite impressed, and it would streamline their "webmaster" tasks. Still, for now, explaining the numeric ordering concept is not too bad (so long as they can "see" the weight numbers, clients seem to understand what's going on).

Best,
Ryan

@mattapus : Thanks for your tip in #23, it helped me a lot sorting my blocks correctly.

The patch in #21 works great. Thanks, guys

#21 works well for me too.

patch #21 works, though it would be better if the select would be placed after the [x] in the last table cell. And drop/hide the label to save space.

patch for #32 included (to be used after #21)
thanks @rudiedirkx

Hi Ryan (sorry for the long delay in my reply),

I can't actually remember if I tried to apply it relative to the plugin directory or module directory. But it certainly is possible that that is what I did, and as you say, the patch I have created is relative to the plugin directory.

Re creating a patch in netbeans local history rather than SVN or CVS diffs, you can do this by:
1) In Projects window, select the module directory
2) In the top menu, select Team and then Export Diff Patch
3) Navigate to where you want to save it, and export

I am using Netbeans 6.9, so it maybe a bit different in 6.8, but I believe it is the same.

Regards
Blair

A bit of a cheat fix here for those who don't want to add a patch.

Using Firefox and the Web Developer Toolbar app there is a setting to turn off all CSS styles. When you turn off the styles the Weights become visible. Then you can change the Weights to what you want.

I find that it's easiest to set them to "0" then the Ajax feature starts working again.

Hi Seanenroute,

If I remember correctly, exposing those weights in the manner you noted (clever find by the way) will not actually do anything. Even if you enter a new value in the exposed weight field (ie. '0'), it will not be used.

At a code level I don't fully understand the native ordering process that context uses for weights, but it seems to determine the order with some javascript that's independent of the "weight" field. I think it just looks at verbose order of the rows in the table each time you save a context, and then re-writes it's internal weight records accordingly. I believe this is why each time you re-save a context - even if you don't change any block ordering - your weights may be re-written (which is especially frustrating if you already worked hard to get the order correct with the inline editor).

The patch makes sure those weight fields are used... no matter how they are exposed. The patch also makes some css changes that expose the weights (much like you did manually), but without the other changes implemented by the patch, those weights simply won't be used.

I haven't looked at the code for many weeks... so I'm going off of memory here. Hope I'm not missing something or misunderstanding.

Cheers,
Ryan

Good stab @Ryan, but this needs better solution.

For this issue to be fixed Context should change weights for all blocks of all active contexts per page per region. There is no easy way out.

Something like this should happen - when block is added to region Contexts should check if other contexts has blocks in that same region and adjust those blocks in those other regions accordingly too.

Just tested over and over and it looks like there is not a bug. Weights look normal and sorts across contexts in same region in function 'block_list'. Only problem I saw was that in my case only 'section_front' context block could be dragged above or below block in 'global' context. 'global's block just sits there, no dragging for that while editing it's context.

I thought I had a problem, but then again maybe I got lost in testing. Anyone can confirm underlying problem with -dev?

Hi LavaMeTender,

I have not yet fully absorbed your comments above, but in #39 are you saying that the patch is actually working for you (no bug)? I'm also a little confused by your comments about a 'global context', are you referring to a sitewide context?

I have a region that is active on front page - sitewide and front. Both has one block and before it looked like order is not saved, but it is.

Ok, thanks, I'll adjust the status back. Your point in #38 implies the use of some form of "global" block ordering system where a user is able to browse and order blocks collected from all contexts per-region, which is similar to the way the core Drupal block system works. This patch doesn't provide that kind of functionality. Instead it only allows the user to manually calculate and apply block weights such that the ordering will be as desired when contexts overlap.

I'm wondering if it might be worth opening a separate issue to get a solution going that will force context to use the block weight values set by the core block system (as these are actually "global")? This approach has its own disadvantages, but I'm guessing it would not be a huge patch to create. Still, I suppose that should be explored as a separate issue.

but you can select to ignore the core block module at admin/build/context/settings. Then what?
I personally don't mind just selecting the weight on the context page.

Unfortunately I must admit I was wrong. Block weights are off again and I have no idea why, after I save them they somehow later switch back. So issue is valid and needs proper patch. I cannot tell clients to use manual wights, since its not 1998 anymore. Will dig deeper.

LavaMeTender,

• Many nuances and shortcomings about dealing with blocks in overlapping contexts are addressed in various posts above (#17 for example). Be sure you check those out
• This patch not only exposes the numeric block weights for manual changes, but it also ensures that those numeric weights are maintained upon subsequent saves to the context settings. Without the patch, the behavior is a bit more erratic, and some weights may appear to be "reset" when you re-save a context.
• This patch does not work well with the inline editor. This means that the inline editor will simply take-over and override any specific numeric block weights that you set
• No part of this patch will work if you uncheck the "Expose numeric block weights" options in admin/build/context/settings.
• The option to disable the core block system at admin/build/context/settings has nothing to do with the way blocks set by context are weighted.

Can you confirm that you have the "Expose numeric block weights" option checked and are NOT using the inline editor? After confirming this (and manually setting your weights) do you still have problems?

I agree that this is not the perfect solution. Far from it. This was just a option I discovered that allows users to manage blocks within complex overlapping contexts. Even though the interface is still "1998", it hopefully empowers people to deal with the issue in a way they simply can't using context out-of-the-box (until a more powerful option is available). I'm sure you and your clients would agree that the inline editor is more a "2010" solution, and though it does allow you to setup correct block ordering in overlapping contexts, maintain that ordering is a tricky process. Perhaps manually-defining the weights can overcome this until a better solution is built.

Sure, Ill test. In no means I ment to say that somehow any effort is useless.

Subscribing.

Subscribing. Works for me so far :) Very handy.

rjacobs #45 2nd point: If patch now fixes saving of weights, what would be next step towards possibility to hide manual weight adjustments again?

Hi Lavametender,

I wouldn't say that the patch "fixes" the way weights are saved, it simply overrides the way weights are set when you save or adjust a context via admin/build/context. Basically, it uses the manual weights you set instead of the internal ordering calculations that context uses (which don't factor in the ordering and weights of other blocks from other contexts in the same region). So I suppose the trade-off is that you have to do the manual calculations yourself, but you have more control to factor in overlapping contexts.

My guess is that a proper solution that hides the manual weight adjustments (while still allowing overlapping contexts to be "aware" of each-other), would not build off of this one.... it would probably be a whole new concept/patch of its own.

I suppose a simple alternative would be a solution/option that forces context to use the block weight values set by the core block system (via the tabledrage mechanism) in a "global" way. That's come up a couple times, and would have to be a separate patch (maybe a whole new D6 issue). There could be lots of ways to address this problem I suppose, but I imagine many of them could be pretty complex to implement, especially one that's friendly with the inline editor. Someone what understands the inner-workings of context better than me would be required to tackle the 100% "correct" solution... whatever that turned out to be conceptually.

Would the best solution not be to allow weighting of each context as a whole?

The context as a whole is enough if you use a context per block, or if your block ordering is ok with having all blocks in a context arranged sequentially.

If one wishes to do something like

block1_from_context1
block1_from_context2
block2_from_context1
block2_from_context2

that approach is a no-go. And as far as i can tell, this happens a lot.

My guess is that the best approach is the described in #38.
All contexts would have all the blocks per region, just differentiate the current context we're working on with CSS and a label with the tag + name of the context that uses the grayed out block. That way the block order will always be correct.

subscribing
I don't use inline editor because many times it doesn't work with my themes... I don't know why.

subscribing.

subscribing

I have written a module to address this problem, it's far from perfect but could be the most complete solution yet. I really tried avoiding patching context in order for the module to work, though has to make some minor changes in content_reaction_block.js. These changes where only to make the javascript more general, and make ContextBlockForm not use global scope for settings its state.

This is more of a quick-and-dirty proof of concept than anything else, but it works for me, and hopefully the idea could be picked up and/or improved upon by the context maintainers.

Havn't bothered to fix some of the css, and might contain serious bugs since I have not tested it very thoroughly.

EDIT: Short description of what it does. You get a new plugin called 'Block order', this works about the same as the ordinary context block plugin UI-wise, the difference is that it does not place any blocks, just decides the order if blocks from two "ordinary" block contexts needs to be merged.

So if you put a "Block order" in a global context you will have global weights. These could be overridden in other contexts I suppose, but haven't given that much thought yet and many "Block order" contexts could yield unpredictable results.

Founds some errors in the module design, will fix and upload later.

New version:

subscribing...

Why not create this as a patch to the Context UI module? I don't think this needs a dedicated module.

I could re-factor it as a patch instead, but the way I see it this needs to be a separate plugin anyway, and you might as well put that in a separate module. Some small changes in context would make the implementation of this module cleaner, and allow for even more alternative "ordering managers". But first it would be interesting to hear what people think of this module and how it handles the ordering problem.

Even if you set it up as a submodule patch, you will get more eyes on it than a tarball will receive, and in a more timely manner.

I will look into it. One of the reasons I didn't hack away at the context module was because I didn't want to maintain that patch against new versions in case the context team didn't like it. I might have some time to make patch to include it as a submodule of context this weekend (would like to clean up the code a bit etc).

subscribing

subscribe.

subscribing...

I found out that Context Editor allow Drag', Drop to reorder blocks, which works like a charm with multiple contexts enabled at same time.

My 2€cents

@Sylvain_G -- How does one enable multiple contexts at same time within Context Editor?

#21 solved for now... tks.

works perfectly for me, you can drag'n drop blocks even in the middle of 2 blocks enabled by another context.

Cheers

@Sylvain_G, can you confirm something real quick? What happens when you edit and save one of your contexts (via admin/build/context) that already contains special block ordering setup via the graphical inline/context editor? Try saving even without making any changes to the block details.

Unless something has changed recently with context, it's my understanding the block orders are reset/re-calculated each time a context is saved, which can easily break any special ordering setup with the inline editor. See comments #7 (point 3), #8 and #9. I'm just curious if this issues still applies.

@rjacobs you right editing context with admin/build/context resets blocks configuration :( my issue is half fixed :( thanks for pointing out

Okay... I was going to file a similar bug and fortunately found this before filing a duplicate bug.

I installed 6.x-3.0 on my site and was hoping for the "Context Module is Blocks on Crack" experience and am currently frustrated that I can't adjust the block weight or a few other things. I see that there are patches above to properly address this issue and look forward to a version of Context module that implements those patches.

subscribe

subscribe

subscribe.
any particular reason this isn't pointed at dev?

Subscribing

subscribing

subscribing

From what I can tell, the eventual block output doesn't even depend on the alphabetical order of context namespaces.
My "i18n_available" context blocks appear before my "chat_available" context blocks.
Don't understand how because all context block weights are reset to zero on save, and core weights aren't respected.

Just taking care of it with Features for now.

It's worth noting that Drupal 7 seems to incorporate a new feature into "tabledrag" forms which allows weights to be set manually. It looks like it's possible now to toggle between manual weight selections and drag-and-drop ordering in any forms that incorporate weights. Though this appears to be part of the core D7 forms API (and not part of context), it does accomplish the same thing that the patch noted in the first half of this thread (prior to about comment #50) does.... but only in D7.

It looks like this option was added in D7 for accessibility (#448292: Drag and Drop for table rows is not accessible to screen-reader users). It also looks like the D7 context now allows manually-set weight to "stick", which is another D6 context issue that the the first patch addresses (in addition to exposing the manual weights).

I'm not sure if this point is support of the initial patch, or perhaps if some of the code (that D7 uses to implement this feature) could be leveraged in D6 context to improve upon the robustness of the original "expose manual weights" idea. Regardless I though I'd mention it here.

Ryan

subscribing

Subscribing.
This is sorely needed as the inline context editor doesn't always work as one would like.

I have tried the patch in #47 and the module in #59.
The module I couldn't get to work.

The patch seems to work, although you have to add blocks, save, then edit and reorder. I can reorder now though, yay!

#23 was very helpful, the only difference is you need to include a reference to $context.

function mymodule_context_load_alter(&$context) {
  if ($context->name == 'my_context_name_from_the_ui') {
    $context->reactions['block']['blocks']['my_block_name']['weight'] = -99;
  }
}

If you don't know block names, write out the $context->reactions object using dsm() or my favorite variable dumper, flog_it().

I tried the patch in #47 and the module in #59 but neither seemed to work. I checked the box "Expose numeric block weights" at /admin/build/context/settings but it did not seem to do anything. I was expecting to see draggable contexts in the main list at /admin/build/context. Is this not correct or am I missing something.

the patch in #47 exposes weights on blocks in Reactions within a specific context.
this enables administrators to explicitly set block weights so that other context blocks and system blocks can (with some effort) be ordered appropriately.

it does not affect the ordering of contexts relative to one another.

this enables administrators to explicitly set block weights so that other context blocks and system blocks can (with some effort) be ordered appropriately.

@ aaronbauman -- Can you give an example and admin path where / how you would do this? Thanks.

1. change context settings to enable exposed weights - admin/build/context/settings
2. edit a context
3. add a "blocks" reaction
4. add any block to any region
5. save the context
6. edit the context (again)
7. edit the "blocks" reaction -- you will now see the exposed weight.

Also, just a note for anyone interested in the logic behind the patch (e.g. why is making a change at admin/build/context/settings necessary, why must a block addition be saved once before it's weight can be adjusted, etc.), the original explanatory notes in #17 should still apply to the updated patch version in #47.

confirming #47 applied to 6.x-3.0 works beautifully. Thanks!

The patch did not apply for me. Did it manually and rerolled (#47).

As many tested and approved this, I guess it's RTBC.

sub

RTBC.
2.5 years old
Can we get this into dev?

Subscribe. Can we get this into dev version ?

You don't need to subscribe anymore. There's a green "Follow" button at the top right of the issue.

This comment is right: The accessibility solution in Drupal 7 makes weighting blocks over multiple contexts very easy and is the most robust solution I'd expect.

agree with #95. Seems RTBC to me

Hello! I just want to thank all the people working on this patch and really hope, the module maintainers include this in the 6.x dev version.

Just realized the supplemental module is for 6.x after trying to install it on 7.x.

Any chance we can roll this into 7.x?

I recall this is implemented in 7.x already, isn't it (i.e. a 'Show block weights' link)?

Since this is reviewed and tested, I am opening new issue for fixing core of this issue, see here #1468864: Save correct weight for all blocks in all contexts of region when saving.

My mistake anyway, there is that link "Show weights" but it doesn't work.

Surprised this hasn't been committed yet. The last release for 6.x was about 2 years ago...

I tested this patch and worked fine for me

This is RTBC to me too

The module is definitely still maintained.
Maybe it will get some attention if we re-classify as a bug, which is arguably accurate.

@dro0x, check out comment number #82 above. My understanding (and recent experience) is that this is not an issue for D7.

I have the same issue. Created a block using quicktabs. Now select that block in context and set the weight. Displays on page but in wrong order.

patch #93 applies and works fine. +1 for RTBC

Regarding comments 108-111, perhaps someone needs to open-up a separate D7 context issue for this (assuming there is not one open already)? This particular D6 patch is quite specific to the way "tabledrag" ordering works in D6 (and finding ways to expose weights for manual control). From a tech perspective that has changed a bit, in core, for D7.

So I think anyone reviewing the D6 patch can disregard 108-111.

Anyway, that said, I recently did some block re-ordering across multiple contexts in a D7 site and everything appears to work correctly, so it's not a problem I personally have encountered or can duplicate. My only comment (and this applies to D6 under this patch as well) is to remember that any block weights are absolute across contexts. So a block with a weight of 10 in context A will appear below a block with a weight of -2 in context B (when contexts A and B place blocks in the same region). This is always true as contexts themselves do not have a "weight".

@dro0x, sorry for delayed reply... I was not checking in on this thread recently.

bump

I have a pretty nice solution on it's way (for both d6/d7). Will hopefully be able to upload in this thread in a couple of days. (It's a slightly more polished version of my previous attempt in this thread).

i removed blocks from context, added them back through add blocks & changed page visibility settings for those blocks... that did it for me

Concerning #115; created separate issue instead where the patch can be found: http://drupal.org/node/1668580

I was battling with this for a while in D7. Turns out I had my page cached so the block order did not change. Hope that helps someone. :)

I couldn't figure out a good solution to this at all. Coming so late to the party, I wasn't sure the patches above would work. I found that exporting the view and re-importing again with changed block weights didn't help as the block weights were always reset 0, 1, 2, 3, etc on import.

In the end, I've got an ugly but workable fix for the problem like so:

Back up your database. Use phpMyAdmin to edit the Context table. Change the weights for your blocks in the appropriate table field - take care, because it's easy to make a mistake when editing serialised values. Clear your caches in Drupal (or use "drush cc all"). Tada. Works until you next edit the Context when I guess it'll have to be done all over again. Still, it gets the job done.

#93 still works, tks!

bump

#93 applies as is to 6.x-3.3 version

bumping to 7.x as that's the more active branch, patch attached, changing title to reflect what the current set of patches is accomplishing

93 is latest for 6.x

Which file do I patch with 455908-context-weight-123.patch ?

Stinky, that file will patch several files not just one. Patches are to be used in the root of the project for which they are built.

More information can be found at Drupal's patch page.

Hi, Will with this patch it also be possible to have a weight condition of order of context in D7 (https://www.drupal.org/node/455908#comment-8992531)?
greetings, Martijn

Works for me (in several projects) and others too, so marking this as RTBC.

Did someone manually trigger all these re-tests, or do I need to file a bug report with infrastructure?

No. That was expected as the branch had broken tests and I fixed all of them what triggered the test runs.

Maybe I'm missing something, but I think there is another patch that does what this patch does, and more.

The Override Block Titles Via Context UI patch allows users to set weights manually, or drag them to different weights using "tabledrag" functionality. It also provides a way to override default block titles both in the standard Context UI, and using the inline editor. No variable is necessary to enable the functionality.

If you can review the latest patch, I'd appreciate it. It would be good if we can reach a collective decision on any changes that might be necessary between the two. Thanks.

https://www.drupal.org/node/795058