Jump to content


Photo
- - - - -

Adding new sidebars ... messes up configuration


  • Please log in to reply
13 replies to this topic

#1 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 25 March 2012 - 10:49 PM

When I migrated from PlatformPro to PageLines I noticed that the sidebars got completely messed up. What was once in one sidebar had moved to another, etc.

I now realise this also happens if you create a new sidebar in a working PageLines environment. Well at least that's true when you do it the way I did which was:

- Added a new Section called "SensorSidebar"
- Implemented section_persistent() and section_template() in the same manner as was done in other side bars (I copied and pasted from primary sidebar 1)

Code is as follows:

Please Login or Register to see this Hidden Content


I do have my doubts about the "1" parameter being passed into pagelines_register_sidebar. Should this be something else? Will that prevent the cascading problems I'm seeing in terms of widgets association to sidebars?

#2 Simon_P

Simon_P

    Messer

  • Administrators



  • 8388607 posts
  • LocationDevon
  • Framework Version:2.1.1
  • Country: Country Flag

Posted 25 March 2012 - 11:31 PM

its the load order in the widget screen.

#3 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 26 March 2012 - 10:16 AM

Sorry Simon, need a bit more context on how this effects things. If I put a larger number in for a new sidebar -- for the sake of argument let's say I put 100 -- would that prevent the widgets from moving around between sidebars?

#4 Simon_P

Simon_P

    Messer

  • Administrators



  • 8388607 posts
  • LocationDevon
  • Framework Version:2.1.1
  • Country: Country Flag

Posted 26 March 2012 - 09:58 PM

It means 1 loads 1st, at the top of the list.

#5 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 27 March 2012 - 10:29 AM

LOL. Yes I get that Simon. My broader question is ... what is the implication of this and how can I avoid in the future adding a sidebar container and not having all my widgets suddenly start jumping around to new sidebar containers. I guess I can just try this (aka, add another sidebar but add with a higher number) but re-configing all my widgets each time I learn about how this works is a bit painful.

#6 Danny

Danny

    Is Awesome!

  • Moderators
  • 15848 posts
  • LocationManchester, UK
  • Country: Country Flag

Posted 27 March 2012 - 11:17 AM

Hi Ken, Is this question related to your other sidebar question here ?

Please Login or Register to see this Hidden Content



#7 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 27 March 2012 - 01:49 PM

Yup they are related. Not identical but related. Here I was just trying to understand the relationship that side bar containers have with the widgets they contain as I don't want to create a new sidebar in production and suddenly have all my containers pointing to the wrong widgets. I suspect that if I put a higher number into the pagelines_register_sidebar I might avoid this situation but I haven't had the time (or guts) to try it out.

#8 cais

cais

    Newbie

  • Members
  • 7 posts

Posted 27 March 2012 - 08:22 PM

@Ken -
The output generated by this function

Please Login or Register to see this Hidden Content

will differ slightly based on whether you have enabled sidebar priorities under PageLines > Settings > Advanced.

With priorities off, you can expect the value you use in the second parameter to establish the sidebar position at the top of the list, then in its relative order based on where it is found in the actual code.

If you turn on sidebar priorities and use these "position" values, you will replace the default sidebar at that position; and the displaced sidebar will be located at the bottom of the sidebar areas.

Using your example

Please Login or Register to see this Hidden Content

would replace the Primary Sidebar; change your example to

Please Login or Register to see this Hidden Content

would replace the "Universal Sidebar".

For reference, the sidebar default priorities are:
1. Primary Sidebar
2. Secondary Sidebar
3. Tertiary Sidebar
4. Universal Sidebar
5. Full Width Sidebar
6. Content Sidebar
7. MoreFoot Left
8. MoreFoot Middle
9. MoreFoot Right
10. Footer Columns Sidebar

Hopefully this will help with sorting out your question.

#9 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 27 March 2012 - 09:19 PM

This great information @cais, thanks! I only have one aspect that I still don't understand ... does this prioritisation have an impact on the relationship a sidebar has to it's associated widgets? The problem I'm experiencing (and this was done by registering as priority 1) is when a new sidebar is introduced the widgets get scattered in a seemingly random order to different sidebar/footers. This is a recoverable situation but a shocking one and very undesirable during the period you're trying to config it back together.

In case my text above is not clear, here's an example:

- let's assume there are three sidebars: primary, secondary, and teriary
- priorities are their defaults (e.g., 1,2, and 3)
- I have assigned the widgets as such:

Please Login or Register to see this Hidden Content


Now I want to add a fourth sidebar -- let's call it sidebar4 for lack of imagination -- and it will in turn get configured with Widget A, G, and H. Before I get to configuring the new sidebar, however, I need to register it. At this point all things go crazy and while all four sidebars exist, they have a random association of widgets. The new association isn't really random, it follows some pattern but I can't discern what that is at the moment. Why did this happen? Is it due to the rearrangement of priorities in the sidebars? If yes then always prioritising new sidebars at the end might help but it also leaves some concerns as to the robustness of the sidebar container (this is a WP complaint not PL). If no then what is causing this configuration malfunction?

#10 cais

cais

    Newbie

  • Members
  • 7 posts

Posted 28 March 2012 - 02:06 AM

@Ken - Have you considered registering the "new" sidebars starting at priority #11 and incrementing as needed, or does your application require you replace the existing sidebars as they are defined? I understand what you are describing, but I am curious if there may be an alternative that will deliver the results you are looking for while still maintaining all of the core sidebar functionality and prioritization.

#11 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 28 March 2012 - 02:11 PM

@cais, it isn't important at all whether my new sidebar's are a higher or lower priority and I'm NOT trying to overwrite the default sidebars. I simply want to add a new sidebar non-destructively.

I believe a picture is worth far more than a 1,000 words so I've created on that shows the destructive process I'm describing. Hope it is clear from this but let me say quickly that I can move back forth between the two states described here by simply adding and/or removing the new sidebar but the priority seems to have no bearing on the chaotic effect of the widgets movement between container sidebar/footer.

Please Login or Register to see this Hidden Content



Posted Image

#12 cais

cais

    Newbie

  • Members
  • 7 posts

Posted 28 March 2012 - 04:17 PM

@Ken - From a coding perspective the behavior you are seeing is perfectly correct. The easiest work-around in this case is to simply turn on Sidebar prioritization (see above) and create your new Sidebar sections with appropriate priority values greater than 10. Under these conditions you should not see the "moving widgets" issues you are experiencing. As a note, the moving widgets are more to do with how WordPress itself stores the information about the default sidebar order, which also leads to another noteworthy detail of sidebars being stored as sidebar-1, sidebar-2, etc. The name of the sidebar that appears in the Widgets page is more for convenience and explanatory purposes. Also to note, the moving widgets can be explained in this example: * There are 6 widgets in the first 3 sidebar areas, we'll call them A, B, C, etc. * The first sidebar has widget A; the second sidebar has widgets B, C, and D; the third sidebar has widgets E and F * Consider a default installation (for example, prior to adding your custom sections) and you will find by default: widget A in Footer Columns Sidebar; widgets B, C, and D in MoreFoot Left; and widgets E and F in MoreFoot Middle. * Now, lets add a single custom sidebar area (your example SensorSidebar as originally noted) and we will have: widget A in SensorSidebar; widgets B, C, and D in Footer Columns Sidebar; and widgets E and F in MoreFoot Left. This is the "pattern" you are seeing. The key is to make sure sidebar prioritizing is enabled, and your custom sidebar sections are using priority values greater than the defaults. These custom sidebar section values should also be appropriated set to not create further conflicts amongst themselves.

#13 ksnyde

ksnyde

    Super Member

  • Members
  • 177 posts
  • Framework Version:2.3

Posted 28 March 2012 - 08:56 PM

@cais, thanks a ton. Very good and complete description. I've tried out your suggestion and it works like a charm.

#14 cais

cais

    Newbie

  • Members
  • 7 posts

Posted 29 March 2012 - 02:24 AM

@ksnyde - You're very welcome, Ken ... glad to be of service.