ianarmstrong

Awesome, I’ll let Vlad over at WPMU know as well. He had trapped and corrected the problem in his own future versions as well so at the end of the day, you are both running more solid plugins.

Thanks!

Uh, wow…

For those who get here via Google:
https://blog.no-panic.at/2006/11/16/hatom-and-wordpress/

This can be done from the theme, though Ozh should probably do it himself as well. The solution is to use a CSS gradient with a fallback to flat gray and completely eliminate the outdated graphic approach.

First, declare an admin stylesheet:

function customAdmin() {
    $url = get_settings('siteurl');
    $url = $url . '/wp-admin.css';
    echo '<!-- custom admin css -->
          <link rel="stylesheet" type="text/css" href="' . $url . '" />
          <!-- /end custom adming css -->';
}
add_action('admin_head', 'customAdmin');

Then add the following CSS definitions:

#ozhmenu {
background: rgb(81,81,81);
background-image: none;
background: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiA/Pgo8c3ZnIHhtbG5zPSJod…EiIGhlaWdodD0iMSIgZmlsbD0idXJsKCNncmFkLXVjZ2ctZ2VuZXJhdGVkKSIgLz4KPC9zdmc+);
background: -moz-linear-gradient(top, rgba(81,81,81,1) 0%, rgba(14,14,14,1) 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(81,81,81,1)), color-stop(100%,rgba(14,14,14,1)));
background: -webkit-linear-gradient(top, rgba(81,81,81,1) 0%,rgba(14,14,14,1) 100%);
background: -o-linear-gradient(top, rgba(81,81,81,1) 0%,rgba(14,14,14,1) 100%);
background: -ms-linear-gradient(top, rgba(81,81,81,1) 0%,rgba(14,14,14,1) 100%);
background: linear-gradient(to bottom, rgba(81,81,81,1) 0%,rgba(14,14,14,1) 100%);
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#515151', endColorstr='#0e0e0e',GradientType=0 );
border-bottom: 2px solid black;

#ozhmenu img.wp-menu-image {
height: 18px;
}

Ozh may fire its own background second, in which case you will have to use specificity or the !important tag to override it.

I went over the script with my PHP guy and we decided that, without restructuring your logic a bit, it would be difficult to make the kinds of changes I wanted in a practical way. Ideally, the plugin would invoke the WP media uploader and display a resized thumbnail in the comment body.

The JS solution made a nice stopgap though and I hope someone finds it useful ??

For now, combined with NicEdit, it creates a much slicker interface than what is presented by default.

https://imperativeideas.com/dev/final.png

Hey Tom,

Enqueue this to the footer of comments.php (or ideally just hook it) and think about adding a theme option for file size.

<script>
    document.forms[0].addEventListener('submit', function( evt ) {
        var file = document.getElementById('comment_image').files[0];

        if(file && file.size < 153600) { // 150k (this size is in bytes)
            //Submit form
        } else {
            //Prevent default and display error
            alert('File size is too large, please reduce and try again');
            evt.preventDefault();
        }
    }, false);
</script>

That does the trick.

Also, in plugin.php, consider modifying the display code:

<a href="' . $comment_image['url'] . '" rel="PrettyPhoto"><img src="' . $comment_image['url'] . '" alt="" /></a>

The rel won’t do a thing if PrettyPhoto isn’t installed but if it is, it’ll trigger the plugin. You can ignore that or make it an option but the link to full size is nice.

Finally, the following CSS:

p.comment-image img {max-width: 45%;}
span.warning {color:indianred;}

In addition to a warning:
$html .= __( '<br><span class="warning">File must be smaller than 150k or submit will fail</span>', 'comment-images' );

Makes a it a much more functional tool.

Cheers.

Good to know. I can get it to die if I do a file check but it does an ugly die and then posts the comments with the image stripped anyway. It’s sub-optimal. I can remove the else and it posts the comment but silently strips the image.

// If the nonce is valid and the user uploaded an image that is less than 150kb, let's upload it to the server
		if( isset( $_FILES[ $comment_image_id ] ) && ! empty( $_FILES[ $comment_image_id ] ) ) {
            if ( $_FILES[ $comment_image_id ]['size'] < 153600 ) {

                // Store the parts of the file name into an array
                $file_name_parts = explode( '.', $_FILES[ $comment_image_id ]['name'] );

                // If the file is valid, upload the image, and store the path in the comment meta
                if( $this->is_valid_file_type( $file_name_parts[ count( $file_name_parts ) - 1 ] ) ) {;

                    // Upload the comment image to the uploads directory
                    $comment_image_file = wp_upload_bits( $_FILES[ $comment_image_id ]['name'], null, file_get_contents( $_FILES[ $comment_image_id ]['tmp_name'] ) );

                    // Now, we need to actually create a post so that this shows up in the media uploader
                    $img_url = media_sideload_image( $comment_image_file['url'], $post_id );

                    // And strip out the name of the image file so we can save this to the meta data
                    // Regex is usually bad for this, but WordPress is predictable in the format
                    preg_match_all( "#[^<img src='](.*)[^'alt='' />]#", $img_url, $matches );
                    $comment_image_file['url'] = $matches[0][0];

                    // Set post meta about this image. Need the comment ID and need the path.
                    if( false == $comment_image_file['error'] ) {

                        // Since we've already added the key for this, we'll just update it with the file.
                        add_comment_meta( $comment_id, 'comment_image', $comment_image_file );

                    } // end if/else

                } // end if

            } else { die; }
        }

Haven’t had time in ten months? You’ve got a very popular plugin man, at least stick it on Git and request a fork.

WAMP in particular doesn’t like the https:// connect option. Disable it in development and re-enable it in production.

Linking your site instead of the plugin URL would probably help

Solution: https://gist.github.com/3184243

Most people who stumble on this will want to comment out the part that adds page descriptions to each menu item. The author, in addition, has put out a full WP theme based on Bones + Foundation 3

https://github.com/awshout/Foundry

Cheers

Ok, Foundation 3 needs the classes in place well before they are added by jQuery. It’ll have to be a custom walker.

Huh, forgot the JS DOM changes never show in the source. Guess that’s not the issue. I’d still prefer a custom walker though since I’ll need to build one for all of the F3 menu types. Will post if I figure this out before someone else does.

I have only ever seen this error after moving WordPress from a DEV to a permanent location. It occurs because of an issue with the Janrain Engage plugin, post move.

Check your plugins, one of them is causing the issue.

Based on the piece of code the OP has posted, he is working through the Lynda.com tutorial on custom post types. I’ve done that one and it does have a glitch in the latest version of WordPress but it’s not WP’s fault.

If subsequent help seekers find this post, they need to wait for the next chapter when:

$args = array(
	'label' => _x('Foos')
	'singular_label' => _x('Foo')

Becomes:

$args = array(
	'label' => _x('Foos', 'post type general name'),
	'singular_label' => _x('Foo', 'post type singular name')

At which point the second argument DOES exist and the error message goes away. By simply eliminating the argument call, they invalidate the custom description of their label.