ottmance

Damn, well the backticks got all messed up in that shell script.

Ok the list of image files in the previous message are fed to this page:

https://opexsociety.org/featured-articles/operational-excellence-manifesto/

Now the issue was that the OpEx-Manifesto-Alfa-Slab-Noise-720×482.png was the file that was getting fed to the browser mainly because the bulk optimizer didn’t create a webp version of the file. I’ve subsequently used the script below to generate the missing files in some of the directories.

As I looked further into this I noticed there were many png or jpg files that didn’t have an associated webp file so I figured I’d do a crash course in bash scripting and try to come up with something that would bulk convert jpg or png files using the API. What I came up with is the following

#!/bin/bash

# Optimus.io API image converter
# Convert image (jpg, png) to webp

# Usage: makewebp.sh image.png .png
# Usage: makewebp.sh image.jpg .jpg
# Usage: find  -type f  -name "*.png" -exec ./mkwebp.sh {} .png \;

name=$1
ext=$2
dir=<code>dirname $1</code>
cvt_name=$dir/<code>basename $1 $2</code>.webp
key=<insert API key here>

if [ ! -e "${name%.*}".webp ]; then
        if ((<code>stat -c%s $1</code> >= 5242880)); then
                echo "***Error $1 exceeds 5MB filesize limit ***"
                echo ""
        else
                echo "Converting $1"
                curl --data-binary @"$name" -o "$cvt_name" -H 'user-agent: Optimus-API' -H 'accept: image/*' https://api.optimus.io/"$key"?webp
                echo ""
        fi
fi

It’s not pretty but it works. I’m not a bash scripting genius by any means but I think I did pretty well on my first go. Sure it could be better and maybe it will at some point.

Also of note I’ve added this to my .htaccess file

<IfModule mod_rewrite.c>
  RewriteEngine On
  # check if browser accepts webp
  RewriteCond %{HTTP_ACCEPT} image/webp 

  # check if file is jpg or png
  RewriteCond %{REQUEST_FILENAME} (.*)\.(jpe?g|png)$

  # check if corresponding webp file exists image.png -> image.webp
  RewriteCond %1\.webp -f

  # serve up webp instead
  RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]

</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept env=REDIRECT_accept

</IfModule>

AddType image/webp .webp

Not 100% sure if that’s correct but it doesn’t seem to break things all over the place if it isn’t. If I use the developer tools in Chrome to look at the content I’m getting I notice the bulk of the images are showing the webp image format in the type column so that’s a good thing.

Is this the “proper” way to go about this? Is there a better way?

Thanks
Chuck

Disregard this here. Logged on the pro suppor boards

Thanks
Chuck

I tried using another CSV importer but wasn’t having much luck with it. Some fields would import and others wouldn’t. Tried creating a bunch of locations and none of the address data would come in. I’ll have a look at that other importer but the more closely I look at this plugin the less I like it. Now don’t take that the wrong way, its a fine plugin, perhaps even a great plugin but there are a few things missing that I need and I need them to “just work” right out of the box.

Chuck

Further testing on a local install via XAMPP gets me the same problem unfortunately.

I’m having the same issue, however it works just fine if you view the post/page via the preview button. Doesn’t display anything when viewing the actual post/page.

Chuck

Anybody?

So to go back to an earlier question

Are there any other plugins?

The answer is yes, the CIMY User Extra Fields Plugin. Disabling this plugin now has things working. The registration process is working noticeably different without this plugin enabled. I’m only asked for a username and an email address and WP generates a random password and emails it to the account entered. This seems to be the normal way of WP and I’m fine with it.

For the hell of it I just renamed the wp_signups table to be wp_signups2

I created a new user which immediately generated an email for me to complete the activation of the account. Yay, an email!!

Clicking on the link in the email gives me this

ERROR: Sorry, that key does not appear to be valid.

Booooo, an error message!!

Plenty of other plugins but none that deal with the login process other than TML.

And yes the wp_signups table gets populated when I create a new user on the site but wp_users table does not get populated. This is probably why the user can’t login when they try.

He’ll if I know Jeff. The table is in the database and records get written to it. I created a page template that does an is_multisite function call just to make sure I’m not going crazy and it cones back false.

For whatever reason that I haven’t been able to figure out or for that matter replicate I did eventually get an email back after creating a user. However when I actually tried to login as that user I was unable to. Something strange is going on here.

Well it’s not a multisite so maybe that’s part of the issue.

That’ll do it every time. Stared at it for so long I couldn’t see it.

So as to the CSS. I tried this out. I loaded the style from version 1.11.2 because that seems to be the version of the jquery ui that WordPress is loading.

wp_enqueue_script('jquery-ui-accordion');
		wp_register_style('jquery_ui_example_css', 'https://code.jquery.com/ui/1.11.2/themes/flick/jquery-ui.css');
		wp_enqueue_style('jquery_ui_example_css');

While it looks better its still non-functional. Getting closer.

Thanks
Chuck

Ok lets assume I have no access to the contents of the functions.php file because i’m writing a widget that i’m planning to distribute. At least I am assuming i wouldn’t have access to the functions.php file in this case but there may be something about packaging a widget that I just don’t understand just yet.

So anyway here is a real basic widget example. It looks almost identical to what i’ve got going on with my widget but all the guts have been removed leaving only the jQuery accordion UI stuff.

<?php
/*
Plugin Name:  jQuery UI example
Plugin URI:   https://www.someurl.com
Description:  Show a jQuery UI Accordion control on a widget form
Version:      0.0.0
Author:       Me
Author URI:   https://www.someurl.com
*/

class jquery_ui_example_widget extends WP_Widget {

    /** constructor */
    function jquery_ui_example_widget() {
        parent::WP_Widget(false, $name = 'jQuery UI Example Widget');
    }

	/** @see WP_Widget::widget */
    function widget($args, $instance) {

	}

	/** @see WP_Widget::update */
    function update($new_instance, $old_instance) {

	}

	function form($instance) {

		wp_enqueue_script('jquery-ui-accordion');
	?>
		<script>
			jQuery(document).ready(function($) {
				$('#accordion').accordion();
		</script>

		<div id="accordion">
		  <h3>Section 1</h3>
		  <div>
			<p>
			Mauris mauris ante, blandit et, ultrices a, suscipit eget, quam. Integer
			ut neque. Vivamus nisi metus, molestie vel, gravida in, condimentum sit
			amet, nunc. Nam a nibh. Donec suscipit eros. Nam mi. Proin viverra leo ut
			odio. Curabitur malesuada. Vestibulum a velit eu ante scelerisque vulputate.
			</p>
		  </div>
		  <h3>Section 2</h3>
		  <div>
			<p>
			Sed non urna. Donec et ante. Phasellus eu ligula. Vestibulum sit amet
			purus. Vivamus hendrerit, dolor at aliquet laoreet, mauris turpis porttitor
			velit, faucibus interdum tellus libero ac justo. Vivamus non quam. In
			suscipit faucibus urna.
			</p>
		  </div>
		 </div>
	<?php
	}

}

// *** Register the widget
add_action('widgets_init', create_function('', 'return register_widget("jquery_ui_example_widget");'));

?>

With the above i get no “accordion” action going on. I’m wondering if there’s some CSS missing here as well.

Thanks
Chuck