ServerStorm
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: All Widgets Fail After WP LoopWow the problem was misleading. It turns out that in both cases the widgets that didn’t appear to working had funky C.S.S. attached that either rendered them well of the screen/hidden or behind something with a higher z-index. It took about 5 minutes looking in Firebug to see what was happening… there was a big waste of 3 hours for something so simple – Lesson learned just like when your electronic device doesn’t turn on check if it is plugged in before diagnosis the hardware I should have checked the display/rendering logic before diving in looking for a code/cache/voodoo solution.
I love this forum cause the three times I’ve posted know one – not even esmi – has answered my posts and I end up having to figure things out myself. While that’s good, I asked the questions to try to save the time, but I guess either I don’t ask well enough or the topics I am discussing are of interest to very few?
Cheers,
SteveForum: Fixing WordPress
In reply to: problem #1 – is it just me, or is WP SL-O-O-O-W…?Is your other raw code site use PHP and/or MySQL (or other Db) or is is xhtml, javascript, and css only?
If it doesn’t use a Db then the load on your Db at godaddy could be significant but you won’t experience it with your raw site but defintely will with your WP site.
If you know how to write a little SQL, script up a timing script for a full table scan, transactions and indexed columns and you will see/tell that this either is or isn’t your bottleneck.
I don’t know if this will help, but one idea for you to support images loading the appropriate width/height for the media connected to your site is to use media queries in your css.
You do something like:
- Put all your main layout css for the ‘full size’ site including the largest of your images
- Then you specify your media queries that wrap anything that should happen for a given size display, like:
- [CSS moderated as per the Forum Rules.]
- Then for a smaller screen or when a browser is resized you might use:
- `@media screen and (max-width: 760px) {
#nav-main {
clear: left;
float: left;
}
#nav-main li { margin: 0 .5em 0 0; }`
- You can see that by the two media queries shown above we do different things with the nav menu if the screen is 1200 or bigger than we do if the screen/browser is between 760px and 1200px
- This same idea works for images where you might go like:
- in the 1200px and above you could have and image of candy set like this:
#feature-candy { background-image: url(images/icon_candy_128-trans.png); }
- for the media query that is 550px or smaller you change the size of the candy image:
@media screen and (max-width: 550px) {
#feature-candy { background-image: url(images/icon_candy_64-trans.png); }
Then you just need to make sure you upload the different sized images to your server.
Regards,
SteveForum: Plugins
In reply to: Widget Displaying but not savingHi,
I got this working but I needed to make a small change.
Here is my function.php code for the widget:
function quickchic_widgets_init() { /* register_sidebar(array( 'name'=> sprintf(__('a_%d'), $i ) ,'id' => 'widget_$i' ,'before_widget' => '<div id="%1$s" class="widget %2$s">' ,'after_widget' => '</div>' ,'before_title' => '' ,'after_title' => '' ));*/ register_sidebar( array( 'name' => __( 'Top Left', 'ciia' ), 'id' => 'sidebar-1', 'before_widget' => '<div id="%1$s" class="widget %2$s">', 'after_widget' => "</div>", 'before_title' => '', 'after_title' => '', ) ); }
You can see the new register_sidebar() ‘Top Left’ and you can see the more generic function of register_sidebar() sprintf(__(‘a_%d’), $i ) that I have commented out.
Then in header.php the relevant widget code is:
<?php dynamic_sidebar( 'Top Left' ); ?>
Now when I add plugins to this widget it works; it saves.
I believe this was a problem with generic function that I had.
Hope this helps.
Steve
Forum: Plugins
In reply to: Widget Displaying but not savingInterestly, If I enable assessibility mode then I assign a plugin to the a_0 widget then save. It does retain the instance even with refreshing the Widget Admin; however there is not way to edit what was originally set.
Yes I did rename the widget to a_? as I read a google thread on capital names of widgets causing problems in version 3; I am using version 3.2.1
This is true even shutting off assessibility mode the assigned plugin does not show as associated with the a_0 widget, and there is not a way to edit it in assessibility mode; just add and inactive functionality is available.