<div id=”wrapper”>

<div id=”sidebar”> ….  </div>

<div id=”content”> …. </div>

</div>

And you are stuck in the situation not knowing when the content would overflow, then you probably need to do:
#sidebar { position: absolute; height: 100%; }
Which would apply the auto-full-height to the sidebar. The only extra thing you might need is positioning the sidebar itself. The wrapper needs some positioning so that the inherited divs are aware of the positioning rules.

Kovshenin was my savior once again for the image_make_intermediate_size function.

Unbelievable.

Did you know that you can image_make_intermediate_size() in #WordPress to explicitly resize an image? Don't forget to update_attached_file()

March 5, 2012 4:59 pm via webReplyRetweetFavorite

@kovshenin

Konstantin Kovshenin

The short version is installing the module as per this tutorial – http://ubuntuforums.org/showthread.php?t=525257

sudo apt-get install php5-dev php-pear

sudo pecl install xdebug

sudo updatedb
locate xdebug (this one finds the xdebug path)

sudo gedit /etc/php/apache2/php.ini

Adding this line (/w the path):

zend_extension="/usr/lib/php5/20060613/xdebug.so"

sudo /etc/init.d/apache2 restart (or sudo apache2ctl restart)

This install the xDebug and enables it.

Then we need to add a few more lines of code in /etc/php5/apache2/php.ini (as in here):

http://holisticsecurity.wordpress.com/2011/07/04/php-xdebug-xampp-win32/
xdebug.auto_trace = 0
xdebug.collect_includes = 1
xdebug.collect_params = 0
xdebug.collect_return = 0
xdebug.collect_vars = “Off”
xdebug.default_enable = “On”
xdebug.dump.COOKIE = “”
xdebug.dump.FILES = “”
xdebug.dump.GET = “”
xdebug.dump.POST = “”
xdebug.dump.REQUEST = “”
xdebug.dump.SERVER = “”
xdebug.dump.SESSION = “”
xdebug.dump_globals = 1
xdebug.dump_once = 1
xdebug.dump_undefined = 0
xdebug.extended_info = 1
xdebug.file_link_format = “”
xdebug.idekey = “”
xdebug.manual_url = “http://www.php.net”
xdebug.max_nesting_level = 100
xdebug.overload_var_dump = 1
xdebug.profiler_append = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 0
xdebug.profiler_output_dir = “/tmp”
xdebug.profiler_output_name = “xdebug_profile.%R::%u”

; xdebug.remote_autostart
; Type: boolean, Default value: 0
; Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Remote
; Debugging). When this setting is set to ‘On’ Xdebug will always attempt to start a remote debugging
; session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.
xdebug.remote_autostart = 1

; xdebug.remote_enable
; Type: boolean, Default value: 0
; This switch controls whether Xdebug should try to contact a debug client which is listening on the
; host and port as set with the settings xdebug.remote_host and xdebug.remote_port. If a connection
; can not be established the script will just continue as if this setting was Off.
xdebug.remote_enable = 1

xdebug.remote_handler = “dbgp”
xdebug.remote_host = “localhost”
xdebug.remote_log = “none”
xdebug.remote_mode = “req”
xdebug.remote_port = 9000
xdebug.show_exception_trace = 0
xdebug.show_local_vars = 0
xdebug.show_mem_delta = 0
xdebug.trace_format = 0
xdebug.trace_options = 0
xdebug.trace_output_dir = “/tmp”
xdebug.trace_output_name = “trace.%c”
xdebug.var_display_max_children = 128
xdebug.var_display_max_data = 512
xdebug.var_display_max_depth = 3

Then create an Eclipse project, click the Debug Configurations

Create a website configuration, select Xdebug, set the paths for the index.php and configure project names; set the web server as well so that this could run smoothly.

Run the project in Debug perspective.

It contains most of the important snippets required for every plugin – registration of custom post types or taxonomies, registering activation and deactivation hooks, admin pages, metaboxes. I’m going to add widget/shortcode registration with some samples. This would make it easier to use it as a new plugin startup script and save some time about it.

I also brainstorm on the idea of making it hookable with parameters so all functions are dynamic and the script could be extended directly with inheritance or composition. Still I need to think more generally whether it would be practical and doable for all functions.

I’ve been developing a script last week that required eval() execution. I did pretty granular input validation with regular expressions and known troubleish test cases. Still, some expressions passed to the eval() function were prone to parse errors.

Reading a bit I tried to use the exceptions handling mechanism in PHP 5 (try – catch blocks) to provide a solution, or using a error handler with the set_error_handler function. They work for exceptions and some basic errors, but most of the errors (including the parse erorr) pass.

I don’t mind the system being unable to call a valid function, but I want to protect the frontend. So the best call I found is using this trick.

Create a function with this content:

return @eval('return true;' . $code);

Where $code is the code you need to normally call in eval().

This statement returns true if your eval is valid – or false if it is going to break. Without breaking the frontend and the PHP execution.

So calling this before running your eval and testing for true will prevent the ugly errors on the page load.

In this review I’m going through the list from the site summarizing what is the overall experience from people reading the WPShout site and adding my 2 cents to the big picture. If you wonder what’s the cosiest cavern for your WordPress systems, you should definitely check this out.

This is my first podcast introducing some of the new features and important notes about the platform.

Should you be interested in these podcast attempts, don’t hesitate to comment.

First of all, I have a quick video on install on Screenr for Progressio - http://www.screenr.com/DcLs

Two important tips:

1. When you download a theme, you need to actually add it to a WordPress installation. This means that you install WordPress, then you upload the theme either via the admin or in your_install/wp-content/themes.
2. When you are ready with the install, point your URL to your_install folder, and not directly to the theme.

Since we’ve found it we no longer use the BackupBuddy plugin (except for some specific cases of course). However ManageWP let us clone our installs and do fresh installations for demos and testing and many more.

It’s free for up to 3 websites and some symbolical price for more websites. Our testing department is really grateful for that chance now.