• 0
Sign in to follow this  
Followers 0

Adding new sidebars ... messes up configuration

Question

Posted · Report post

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:

class SensorSidebar extends PageLinesSection {
	
		/**
		* PHP that always loads no matter if section is added or not.
		*/
	   function section_persistent() {
			$setup = pagelines_standard_sidebar($this->name, $this->settings['description']);
			pagelines_register_sidebar($setup, 1);
		}
	
		/**
		* Section template.
		*/
	   function section_template() {
		 	 pagelines_draw_sidebar($this->id, $this->name, 'includes/widgets.default');
		}
	
	}

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?

Share this post


Link to post
Share on other sites

13 answers to this question

  • 0

Posted · Report post

its the load order in the widget screen.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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?

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

Hi Ken, Is this question related to your other sidebar question here ? http://www.pagelines.com/forum/discussion/18694/an-explicit-sidebar-call

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

@Ken - The output generated by this function [code]pagelines_register_sidebar($setup, 1);[/code] 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 [b]replace[/b] the default sidebar at that position; [b]and the displaced sidebar[/b] will be located at the [b]bottom[/b] of the sidebar areas. Using your example [code]pagelines_register_sidebar($setup, 1);[/code] would replace the Primary Sidebar; change your example to [code]pagelines_register_sidebar($setup, 4);[/code] 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.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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: [code] - primary - Widget A and B - secondary - Widget C and D - tertiary - Widget E, F, and G[/code] 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?

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

@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.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

@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. [url="http://ken.net/screenshot/adding-a-new-sidebar.pdf"]PDF LINK[/url] [img]http://ken.net/screenshot/adding-a-new-sidebar.jpg[/img]

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

@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.

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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

Share this post


Link to post
Share on other sites
  • 0

Posted · Report post

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0