You need to upgrade your Flash Player to version 10 or higher.

So I noticed that when embedding an Iframe, Google Chrome (and Safari) failed to respond to scrolling=no.

I went to look and see if this syntax was deprecated, but its not.

Basically webkit (safari and chrome are based on them) values css styles on the html, body, and others, higher than the actual iframe style itself.

what that means is that if their is an ‘overflow’ attribute as anything other than ‘hidden’ in your applicable css, and you place scrolling=no onto an iframe style or place it in the html itself, chrome and safari will show scroll bars. firefox and IE will not. WTF?

What can you do..

Well you can place the iframe inside a div, call larger than width and heights to eleminate the ‘auto’ scroll bars in chrome and safari, then use a div outside of it with a set height and width as well as overflow=hidden to trim the iframe.

The Cause…

There is an attribute inside your css that calls overflow: scroll, or overflow: auto, or overflow-x: scroll, or overflow-y: scroll, or auto or whatever… If you are lucky enough to be able to pull this css style attribute out, it will fix your problem…

 

Sometimes it is difficult to locate your server path.

Drop this string into a .php file called ‘locate-path’ or something, and then navigate to it in a browser to see your full server path!

<p><?php echo $_SERVER['PATH_TRANSLATED'];?></p>
 

I know that if any of you have used iframes you’ll have noticed the white box that floats there so in-your-face, just taunting you with its uglyness as the rest of the page loads.

Why not take a screenshot of the page when it has fully loaded, crop the img down to just the contents of the fully loaded frame, and then use it as the background for a div container around the frame. an example would be:

<div style="background: url('http://erikshosting.com/childframe/pre-load-screenshot.png');">
<iframe src="http://erikshosting.com/childframe/frame1.php" width="100%" height="211" frameborder="0" scrolling="no" overflow="hidden" name="erocks-global-nav-embed">
You Must Use A Browser Built This Century To See This Frame</iframe></div>
 

*Code snippet for custom walker near bottom. Narrative near top*

I was recently working on a clients project where I needed to draw the primary nav of site#1 onto site #2-5, while retaining its ability to be edited via site#1’s wp menu editor panel.

So what I did was put a php include onto each site that called a seperate php file that had my iframe code in it. This Iframe framed the primary nav menu of the first site, while the 2nd site called the frame file as an include, and the menu was available to the 2nd site as well…

Now for the next problem, the links on the menu were set with the ‘target’ attribute of ‘_self’, meaning that when clicked, they took us to the link in the iframe and not in the full browser window showing the 2nd site. So the obvious solution would be to change the target attribute to ‘_top’.

Turns out that the wordpress Menus Control Panel, has an advanced screen option of ‘link target’ this allows you the options of ‘current window’ or ‘new window’, meaning ‘_self’ and ‘_blank’, respectively. The fact that ‘_parent’ wasn’t included as an option blew me away. So i added a ticket to the wordpress trac and slept on it.

Next day I see in the trac ticket, the begining of an argument about how frames are “too 1995″ and if the  _parent or _top option was necessary for casual users…..

I’m not going to get into how much of an excuse this is for not fixing a glaring omission, but I’m also not going to wait around to see if i can finish my project.

So, I modified the primary menus walker to output slightly different html.

I did this by defining a custom walker in my themes functions.php file, and then calling it as an $arg in my themes header.php where it called the wp_nav_menu function..

So to begin i grabbed wordpress’s default walker code from line #67-92 of /wp-includes/nav-menu-template.php. Then I copied this into my themes functions.php file. I then surrounded this block of code in a class function and remembered to place the } after the block. You can see the default wordpress walker (with the target=”_top” attribute added) and my custom function name surrounding it below. So drop the following code into your themes functions.php file

class erockscustom_walker extends Walker_Nav_Menu
{
function start_el(&amp;$output, $item, $depth, $args) {

global $wp_query;
$indent = ( $depth ) ? str_repeat( "\t", $depth ) : '';
$class_names = $value = '';
$classes = empty( $item->classes ) ? array() : (array) $item->classes;
$class_names = join( ' ', apply_filters( 'nav_menu_css_class', array_filter( $classes ), $item ) );
$class_names = '';
$output .= $indent . '<li id="menu-item-'. $item->ID . '"' . $value . $class_names .'>';
$attributes  = ! empty( $item->attr_title ) ? ' title="'  . esc_attr( $item->attr_title ) .'"' : '';
$attributes .= ! empty( $item->target )     ? ' target="' . esc_attr( $item->target     ) .'"' : '';
$attributes .= ! empty( $item->xfn )        ? ' rel="'    . esc_attr( $item->xfn        ) .'"' : '';
$attributes .= ! empty( $item->url )        ? ' href="'   . esc_attr( $item->url        ) .'"' : '';
$item_output = $args->before;
$item_output .= '<a target="_top"'. $attributes .'>';
$item_output .= $args->link_before . apply_filters( 'the_title', $item->title, $item->ID ) . $args->link_after;
$item_output .= '</a>';
$item_output .= $args->after;
$output .= apply_filters( 'walker_nav_menu_start_el', $item_output, $item, $depth, $args );
}
}

Then I dropped the argument into wp_nav_menu (where the wp3 custom menu is called in your themes header.php), like so:

<?php $args=array('walker' => new erockscustom_walker()); wp_nav_menu($args); ?>

AND BAM! links open in the top window, and everything works as it should!

 

So I found an error on a clients server. They were getting the “Upload Failed! Cannot Create Folder” “Is Parent Directory Writeable”.

And yes the folder was writeable. It was the /blogs.dir/1/files folder. of course I checked it and saw it had the appropriate 775 permissions. So I searched the forums and then contacted their servers customer support.

Turns out the folder AND ALL SUBFOLDERS RECURSIVELY were not ‘owned’ by anyone. (WTF?) This ment that even though 775 permission allowed the owner to write, the server was not the owner…..

What needed to happen was the blogs.dir/ dir and all its subfolders had to be modded by customer support at the hosting company to be owned by ‘apache’. Now that the server was the owner, the server could write to the files.

Sometimes I wonder why people pick the Hosts that they do. I geuss it comes down to money… My advice, buck up and spend a few dollars on a good server.