Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: themes

  • I’m Fine With Envato

    I’m Fine With Envato

    I just don’t use ThemeForest.

    Look. I think Envato is actually pretty awesome. They’ve made a way to help people monetize development within WordPress. I’m all about that! I want to see people making a living from WordPress and I want people to be able to succeed and make WordPress even better. A number of people I know who are currently successfully running their own WordPress related business got started over there.

    So why don’t I use their products? I haven’t had a need to. I don’t use WooCommerce either, or their themes. There’s nothing wrong with that. But there is a ‘problem’ with Envato, or rather there’s one with ThemeForest, and it’s the same problem as we have on the WordPress.org plugin repository.

    The last (and possibly only) time I mentioned them, I said I had an issue with their lack of upgradability. If I buy a theme or a plugin, I can’t easily get updates. I’m stuck on the old way of download when I get an email. There’s no way to do it easily from inside my dashboard. This is a problem of our own creation. Ten years ago, that was normal. Today, we have a reasonable expectation to easily upgrade WordPress, it’s themes and plugins.

    I happen to know Envato’s working on it, so I still look forward to their solution.

    But they have the exact same problem as we have with the WordPress.org plugin repository: crap code.

    You see, there’s only no practical difference between the WPORG repository and ThemeForest and how it handles reviews except they actually may be checking on every upgrade. If you didn’t know, ThemeForest does review things. But they do it exactly like we do! They read the code, they test it, they look for evil things, and they approve or not.

    Theme review on WPORG is a tighter ship than plugin, for a few reasons, but frankly I doubt the overall quality of code on WPORG (plugins) or ThemeForest is all that different. We’ve had some pretty insane vulnerabilities in plugins, after all, and the WPORG repository doesn’t have a great way of dealing with them. But to say that you don’t trust ThemeForest because the code quality is bad while simultaneously using any free plugin from ORG is naive at best.

    The constant problem we have with plugins, and one they have with ThemeForest themes, is that we allow a lot of different types of code. In being liberal like we are, we can allow for a lot more creativity and expression and, well, art. The downside is that there’s a practical limit to what a human being will be able to catch. We’re like the TSA. We try, but we’re fighting a loosing battle and that’s why we’re always going to miss things and we’re always going to be running behind and cleaning up.

    And worse they have the same problem with any code they yank. How do you upgrade everyone? When is it right and safe? When is it an overstep? Weighing security risks with information with compatibility is complex. For the WordPress.org repository, we have a long way to go before we’ll be able to push minor security updates like core can… at least not without a lot of fear and consideration. We’re on the road there, though, so one day you may wake up to a plugin magically secured on your site.

    Oh and as a reminder? If you see a WordPress.org plugin hosted that is insecure or doing evil things, email plugins@wordpress.org with the plugin URL and all the possible information about how it’s insecure. If you know how to hack it, please tell us exactly what you did. You make it faster for us to sort things out.

    For Envato, you can report these things via their Helpful Hacker program.

  • What Themes Get Wrong

    What Themes Get Wrong

    I neither create nor review themes. I can fix a theme and edit one and hack one, but I don’t design them because I don’t visualize that way.

    But boy do I see a lot of themes doing things in a way I can only describe as wrong.

    Packaging and Requiring Plugins

    A lot of themes do this, and I can understand why. If you make a theme that’s meant to be a store, then of course you want it to be used with an ecommerce plugin. That makes sense. But then we have to think about the drama of Revslider or TimThumb and we have to question the themes that throw every feature into their code. Part of development is maintenance. This is an accepted responsibility and, in the case of plugins, we’re all used to upgrading them for maintenance. The same isn’t true of themes. People hate upgrading their themes, and it’s the fault of themes themselves, doing things wrong.

    Forcing Users to Edit Files

    The first week of February I lost my mind at a theme. I had found a user who had run into a mod_security error. They were trying to edit their theme via the WordPress theme editor and hitting save tripped the scanner. Why? The code in the functions.php file was phrased in a way that spooked the scanner. We walked her through SFTP, which worked, and I helped review the security rules to see if we could safely change them. But then I asked her why she was editing the files directly.

    She wanted to edit her footer, to remove the ‘powered by WordPress and Theme’ line, and the only way was to edit the file.

    That couldn’t be right, I shouted at my screen, but I tested and used the theme and was stunned. Yes. The theme was written in a way that the footer wasn’t editable unless you could code and use a hook to unset the action and make a new one. Even just a simple child theme wouldn’t help because the footer was handled in a function and not footer.php

    No wonder users edit themes. But then it got worse.

    Forgetting About Cache

    The top line in the header.php was a forced setting to create a new PHP session. There are a few problems with this. In many cases, having PHP sessions causes a cache to not serve cached files because the forced session tells it that the particular visitor is meant to have a unique sessions and its trying to honor that. The other common situation is that the first person makes the cache with their unique data, and all subsequent visitors get that cached data. Neither is desirable.

    Why do people do it? I presume because when they built their features, they wanted to make sure each user got an individual view. But sessions are a cheap and dirty way about it. Sadly so are cookies, which a cache will either ignore in order to serve cache, or honor and slow a site down.

    People remember to test a theme for speed and features, but so often they forget to test for cache.

    Un-WordPress Designs

    When a theme makes its own custom interface, it’s harder for users to know what to edit and where. It’s the kind of cognitive dissonance that happens when you’re reading a book or watching a tv show and suddenly everything feels wrong. Like if Harry Potter and Dolores Umbridge started dating. Right. That’s how uncomfortable it is to see a theme with its own custom design for the admin pages.

    Let WordPress be WordPress.

    Accessibility

    I don’t meant on the front end. I mean did you know that there are very few themes that, on the back end, are fully accessible to the blind? It’s just not something people think about and it’s the worst thing a theme can do to the world. You may think that only a small part of the world is blind and you may not worry too much about such a small potential user base. But look back to the previous point. The less you design like WordPress the worse it is for users. All users.

    What Do You See?

    What drives you batty?

  • Professional Utility

    Professional Utility

    It’s well known I hate themeing. I can’t really design and I don’t know how to change thoughts to form like that. Words are my gift.

    A year back, I changed this site to using the Utility Theme by Carrie Dils. Since then, I’ve moved on with another theme, for various reasons, but I still found Utility to be one of the nicest, cleanest, themes out there.

    Recently, Carrie came out with Utility Pro and as she’s one of the nicest people out there, offered me a discount. The new theme costs more, starting at $69 and going up to $199 for a professional version with a Gruntified theme and source files. It’s a lot more than the $45 Utility cost, but I went ahead and bought the theme, not having a home for it quite yet.

    After fifteen minutes looking at it and the code, I knew I wanted to use it.

    What Carrie did “differently” with this theme is she made it mobile first. That means the entire site is designed to look good on a mobile device and the breakpoints are used make it look better are larger devices. This is the opposite of what many themes do, designing for large screens and adjusting for smaller. Her ‘media’ section is surprisingly small because of that, and the site resizes quickly and properly with no adjustments needed.

    The next thing she did, and the thing that really was a selling point to me, was she made it accessible. One of the concerns I’ve been struggling with in the last year has been making my content accessible, and in specific my slides. I want everyone to be able to take my content and learn from it, and a theme that considers that means I have to worry less.

    Finally, and here’s where she won my heart, she decoupled code from her theme. This is something that many theme devs and I agree on. A theme should theme, but code should be code. Which means that I don’t want my theme to include custom post types for example. But also she removed Font Awesome. I love it and use it, but by having it in the theme meant that every time the font upgraded, she had to upgrade the theme. We’re all used to upgrading plugins regularly, but themes rarely. By separating the two, she’s able to give the theme stability and the feature flexibility.

    Am I using the theme? Today, yes.

    JFO (A website I run) is Mobile Friendly

    Looks just fine in mobile (Google’s POV is jaded since I block them from scanning things).

    It was the work of a few hours to convert a site from Going Green Pro over to Utility Pro. The only reason it took hours is that I picked up the non-developer version sans Grunt, which meant I had to split out the CSS into my desired sass files, fold in some of my custom functions, and finally fix the problem that had prompted the following comment:

    /**
    This file has been modified by Mika to fit the needs of this.
    If you use it somewhere else, expect breakage. I hard coded
    some things in. Shut up, future me.
**/

    Future me read that and sighed a lot. Finally I removed all the full calls, making everything relative or using the proper functions in order to dynamically add paths. Also I had to merge a Wiki, a Yourls Site, and a gallery into the look, and that meant some serious theme juggling. It didn’t help that with the new layout I decided to tidy up some of the sidebar content and optimize layouts.

    I’ve done very little to rejigger the code. What I’ve messed with is unrelated to what Carrie’s design choices were and more with how Genesis approaches the few things I don’t fully agree with. I’m not yet using the welcome splash screen, since this site people come to for news first, but I plan to use it for major announcements.

    Now, for $69, it’s a well made theme. Would I spend the $199 for the full version with the development tools and the Grunt files and the use on as many sites as I want? If I wasn’t me who liked to play with code and files, yes. If I needed this for clients, most definitely. StudioPress itself charges $59.95 for Genesis, and $399.95 for all themes in their repertoire, so from that aspect, this may seem expensive.

    Chris Lema and I have some strong opinions on the cost of a WordPress theme. When you consider all the things you’re paying for, all the work of testing on mobile devices, accessibility, colors (which are also accessible), compatibility, plus a year of updates and support, that $200 is an amazing price to use on (say) a dozen websites out there.

    I think it’s well worth the price to have this handy in my back pocket for anything I might need it for. And it’s a testament to Carrie how rapidly I realized I did need this and didn’t even know yet.

    Check out Utility Pro. You won’t regret it.

  • Multisite Favicons

    Multisite Favicons

    One of the challenges with WordPress Multisite is that everything is on the same install. This means something that is rather trivial, like a favicon, becomes exceptionally complex and tiresome.

    On a normal site, when I want to make a favicon, I just toss the file into my main HTML folder, next to that .htaccess file, and I’m done. Now, for me it’s a bit of an extra step because I use StudioPress’ Genesis theme, and it applies its own favicon. It’s probably the only thing about Genesis that makes me annoyed, though it’s right next to when my host does that for me. Still, there’s a trick with Genesis.

    Because of Genesis

    Genesis is my parent theme, and it defines my favicon. So I have to delete its and put in mine:

    // No, you may not have your favicon
remove_action('genesis_meta', 'genesis_load_favicon');

add_filter( 'genesis_pre_load_favicon', 'halfelf_favicon_filter' );
function halfelf_favicon_filter( $favicon_url ) {
	return 'https://halfelf.org/code/images/favicons/halfelf.ico';
}

    And it’s that simple.

    But I’m talking about Multisite, and I want to have a different favicon per site, I end up facing a new challenge.

    Because of Genesis and Multisite

    I still need to tell Genesis to shove it, but then I need to check what site I’m on and call the right favicon per site and this works very well. I’m using it today (you can see the code on that other link). But what if there was another option? What if I didn’t have to code it? Because the real problem with that code is I have to do it! If someone wants a new site to have their own favicon, I have to go in and add it to my mu-plugin, save it, commit it, and push it. Ew.

    Jetpack Site Icons

    Jetpack has a newish feature called Site Icon. With that module activated, I can allow each site to upload their own site icon and it will make a mobile icon too where I won’t have to.

    Uploading my Space Invader

    For a Multisite running Jetpack auto-activated on all sites, this is perfect. And yes, I do that because it saves me a headache of having to set it up later. I allow all sites to connect on their own, but I can also control all that from the network admin.

    So what does that old code look like now?

    With Genesis and Jetpack

    Now my code is simple. For everyone, I kill the default favicon, and then I set my own:

    // No, you may not have your favicon
remove_action('genesis_meta', 'genesis_load_favicon');

global $blog_id;

add_filter( 'genesis_pre_load_favicon', 'example_favicon_filter' );
function ipstenu_favicon_filter( $favicon_url ) {
	return 'http://example.com/images/favicons/example.ico';
}

    And the best part is if I set a site icon in Jetpack, it uses that instead.

    Best of both worlds.

  • Gensis: Post Title on Featured Image

    Gensis: Post Title on Featured Image

    This is something that’s done already on my personal blog, and I wanted to repurpose it for another. This was actually very easy, once I reverse engineering a few things.

    Add the Featured Image

    First you have to make sure you have a featured image to add:

    //* Remove default post image
remove_action( 'genesis_entry_content', 'genesis_do_post_image', 8 );

//* Add featured to the entry content - required for the front page/archives
//* With a value of 3 it will be OUTSIDE the <header>
add_action( 'genesis_entry_header', 'halfelf_featured_photo', 3 );

function halfelf_featured_photo() {
	if ( !genesis_get_option( 'content_archive_thumbnail' ) || !has_post_thumbnail() ) {
	    // Don't show on pages without a thumbnail or on archives without a thumbnail but leave space for the compensation.
		printf('<div class="featured-image no-image"></div>');
	}

	elseif ( is_single() ) {
		// No link on single pages
		$image = genesis_get_image( array( 'format' => 'url', 'size' => genesis_get_option( 'image_size' ) ) );
		printf( '<img src="%s" alt="%s" />', $image, the_title_attribute( 'echo=0' ) );
	}

	elseif ( $image = genesis_get_image( array( 'format' => 'url', 'size' => genesis_get_option( 'image_size' ) ) ) ) {
		printf('<a href="%s" title="%s" class="featured-image">', get_permalink(), the_title_attribute( 'echo=0' ) );
		printf( '<img src="%s" alt="%s" />', $image, the_title_attribute( 'echo=0' ) );
		printf('</a>');
	}
}

    I’ve probably made this more complicated than necessary, but I needed the extra div for pages without featured images, I wanted to and I wanted to show the image on post pages without a link, so this was what I made.

    Move the header with CSS

    .entry {
	margin-bottom: 20px;
	position: relative;
}

.entry-content:before {
	clear: both;
}

article .entry-header {
	position: absolute;
	top: 10px;
	width: 100%;
	background: rgba(236, 240, 239, 0.75) !important;
	text-align: center;
}

.featured-image.no-image {
	height: 220px;
	background-color: #333;
}

    I actually use some sass to generate this (thank you Taupecat and my sass plugin) but I’ve put it in plain PX for you. Adjust as needed. The .featured-image.no-image height is to match the height of that site’s featured image, which I always know.

    Style as desired

    I threw in this so the whole image changes color when you hover, as a good indicator to what’s going on.

    a.featured-image:hover, a.featured-image.no-image {
	opacity: .33;
}

    Surprisingly simple.

  • Featured Image Size Redux

    Featured Image Size Redux

    One of my themes didn’t have a Genesis Featured Image.

    Actually it did, but it didn’t have it as an named additional image. And this was a problem because I like to have the featured image size listed in my featured image box, as I explained how to do in my post about how to do this in Featured Image Size. That theme was using the ‘medium’ size for featured images, which meant by code made the box look like this:

    Busted Featured Image Size

    This is because I had no $_wp_additional_image_sizes, and that’s what I meant when I said there was no named additional image size. So I had to change up my calculation and check first if the name of the image size was one of the defaults, ‘thumbnail’, ‘medium’, or ‘large’, and size off that and then check the other options.

    Which gives me this:

    // What is my image size?
add_filter( 'admin_post_thumbnail_html', 'helf_admin_post_thumbnail_html' );

function helf_admin_post_thumbnail_html( $content ) {
	// Define what the name of our featured image size is
	$genesis = get_option('genesis-settings');
	$genesis_image_size = $genesis['image_size'];

	// Get featured image size
	global $_wp_additional_image_sizes;

	if ( in_array( $genesis_image_size, array( 'thumbnail', 'medium', 'large' ) ) ) {
		$size_width = get_option( $genesis_image_size . '_size_w' );
		$size_height = get_option( $genesis_image_size . '_size_h' ); 
	} elseif ( isset( $_wp_additional_image_sizes[ $genesis_image_size ] ) ) {
		$size_width = $_wp_additional_image_sizes[$genesis_image_size]['width'];
		$size_height = $_wp_additional_image_sizes[$genesis_image_size]['height'];
	}

	$my_featured_image = $size_width.'x'.$size_height;

	// Apply
	$imagesize = '<p>Image Size: ' . $my_featured_image . 'px</p>';
	$content = $imagesize . $content;

	return $content;

}

    Right below the global check, I do an if to scan the array and grab the sizes based on that. It’s exceptionally simple, and the major change was moving it to set variables and then setting based on those outside of the if/else check. But it works perfectly on both my sites with regular sizes and the fancy sizes.

    I still don’t have a check to see if the theme is Genesis or not, but this multisite is 100% Genesis for all sites, so it’s not an issue for me. If anyone has a way to check “Is this active theme on this site Genesis or a child,” please share. The world will thank you.