Vince DeSantiago Added To Our Chicago Office

Bright Bright Great is excited to announce the addition of Vince DeSantiago as Art Director to our Chicago-office.

Vince DeSantiago

Vince will be adding on as Art Director, Photographer and Illustrator in our Chicago office.

Vince comes to Bright Bright Great from Walton Isaacson and has previously worked at Delicious Design League & FCB/Chicago. Vince focuses on design with purpose and is an avid fan of all things strange/invigorating and enjoys custom typography.

Follow Vince DeSantiago on Social:

Instagram – Creative Bloq Top 12 Art Directors to follow on Instagram!
LinkedIn
Twitter

Chase Tower

Posted By
Jason Schwartz

HHVM: The Gift That Keeps On Giving

Over the past 20 years, PHP has become the de facto server-side programming language of the web.

From leading open-source software like WordPress to some of the Internet’s most heavily-trafficked sites (Facebook, Twitter, and Wikipedia to name a few), you’ll find it everywhere.

But its developer-friendly syntax comes at a cost.

Before any Web Magic™ can happen, the human-readable PHP source code must be run through an interpreter. This process is expensive (particularly in terms of memory usage) and time-consuming. Ultimately, this sets an upper-bound on the number of simultaneous page requests a given server can handle. As a site nears this ceiling, it becomes necessary to either make the site more efficient, or upgrade the hardware.

For some sites, the answer is to sidestep PHP altogether and implement static page caching. But for others, where dynamic processing is unavoidable, the solution might lie in the interpreter itself.

As system administrators know, there is no shortage of PHP interpreters on the market.

Each has its own quirks, configurations, and compatibility issues, so there is no one-size-fits-all solution. But with a little experimentation and a lot of testing, performance gains can be substantial.

One of the most promising interpreters available today is the Hip-Hop Virtual Machine (HHVM). Developed in-house by Facebook, the name of the game for HHVM is speed. For one thing, HHVM meets the machine halfway, converting PHP source code into an intermediate bytecode (this bytecode, then, is what’s left to dynamically interpret at runtime).

This is similar to what PHP extensions like Xcache bring to the table. Another trick up its sleeves: HHVM uses a single multi-threaded process to handle requests (unlike, for example, PHP-FPM, which spawns multiple processes). This leads to much more stable CPU and memory usage for servers operating under heavy loads.

A couple months ago, one of the more resource-heavy sites managed by Bright Bright Great was suffering from a substantial increase in traffic. While publicity is one of the better problems to have, it did pose difficulties for the server, which simply wasn’t configured for that level of interest.

After some (read: lots of) compatibility testing, we successfully transitioned from PHP-FPM to HHVM. The results were astounding.

The average DOM-Ready time dropped by 46%. Simultaneous page serves increased by 112%. And CPU usage under load, once maxed out, remained stable at a healthy 55%.

In fact, the PHP gains were so successful the bottleneck was shifted to MySQL. After some code rewrites to help the site take advantage of object caching (via HHVM’s implementation of APC), the simultaneous page serving capacity was nearly doubled again.

But wait, there’s more!

As part of HHVM’s regular development cycle, its engineers are locked in a room with a surfeit of junk food and coffee (I imagine) and tasked to further optimize the code already in place. By focusing on improvements that directly benefit widely-used software, the real-world impact of any gains made is maximized. With the recent release of version 3.8, HHVM was able to serve 9.7% more pages per second for WordPress, 4.8% for MediaWiki, and 13.9% for Drupal8 (uncached).

We ran quick before and after tests ourselves (against the site previously mentioned) using the command line program siege. Sure enough, the upgrade was able to serve 4.3% more pages per second.

HHVM is indeed the gift that keeps on giving!

Posted By
Josh Stoik

Apprenticeship Recap – Dayan D’Aniello

Our intern, Dayan, recently returned to school after spending the summer with us. Before he left, we asked him to tell us what he learned during his time in our office.

My name is Dayan D’Aniello and I spent this past summer as a design intern at Bright Bright Great before going back to the University of Florida to finish out my senior year. During my time in the office, I was able to contribute to 5 projects and work on designing a typeface (a little better than just getting coffee, right?).

Dayan

The important thing with any internship is to pick up new lessons and skills that will help you once you start a full-time job and I definitely learned a lot that will help me as I get started in my career. With that in mind, here are my three biggest takeaways from my time at BBG:

Write everything down.

I mean everything. I took 77 pages of notes from various morning meetings. Client interactions, art direction presentations, art direction feedback, et cetera. While I stopped taking notes in my classes, it was definitely necessary to keep track of all the things you’re asked to do: write it down!

Ask questions, but not too many.

Don’t be afraid to shoot someone a message if you’re in need of some help. There is a limit to this, though. Everyone else is busy most of the time, so try to figure it out on your own first instead of making someone feel like you’re trying to source your answers from them.

Everything moves quickly, be ready to hustle.

This one speaks for itself. There were times I was in the office until 2 AM. On a Saturday. You have to put in the work to enjoy the rewards.

And that’s that! Keep track of what I’m up to during my senior year on my Behance page. Keep an eye out for open apprenticeships here.

Posted By
Jason Schwartz

How To Achieve an A+ SSL Configuration on Nginx

Qualys SSL Labs has a wonderful tool to help evaluate your server’s SSL configuration. I recommend you take a moment to scan your site and see how you fare. Go do that now. I’ll wait. If you didn’t get a perfect score, you aren’t alone.

The default configurations for popular server-side software like OpenSSL often support cryptographically weak standards that can put users at risk. Even major corporations have room for improvement.

Keep your server secure

If you’re on a shared server or at the mercy of control panel software like cPanel or Plesk, unfortunately there isn’t anything you can do. But if you have root access and a little knowing of the command-line, this article will help you harden your configuration so you can get a perfect A+.

While the following examples are specific to Nginx, they should be able to help point any readers running Apache or Lighttpd servers in the right direction.

Obtaining a Certificate

First, let’s start with a quick refresher on how you go about getting a certificate in the first place. Make a directory outside your web root, and once in that directory, generate a private key and certificate signing request (CSR). Your key should be at least 2048 bytes. In this example we’ll generate one that is 4096 bytes. If you have an existing key and can’t remember how strong it is, you can type:

openssl rsa -in domain.com.key -text -noout | head -n 1

To generate a new key, use:

mkdir /var/www/domain.com/ssl
cd /var/www/domain.com/ssl
openssl req -new -newkey rsa:4096 -nodes -keyout domain.com.key -out domain.com.csr

The openssl command will quiz you about your domain and organization. The Common Name (CN) needs to be the fully-qualified-domain-name for which you are purchasing the certificate. Remember, domain.com and www.domain.com are technically two different domains, so enter the CN exactly as visitors are expected to reach it. Some certificates, such as Comodo’s PositiveSSL, are magically valid for both www and non-www variants (aren’t they sweet?).

You should now find two files in your ssl directory: domain.com.key and domain.com.csr. That key is meant to be private, so take a moment to update its permissions. If 600 is too restrictive for your environment, 640 might do the trick.

chmod 0600 domain.com.key

Now go buy a certificate. Namecheap offers decent Comodo certificates from as low as $9, or you could spend more money elsewhere. It doesn’t much matter. As part of the certificate activation process, you’ll be asked for the CSR you just created, so keep that handy. Different Certificate Authorities (CA) have different validation processes, so just follow whatever instructions you’re given.

Once your certificate has been issued, upload them to the directory containing your key and CSR. If you are issued two or more bundled certificates (which is a common practice), they must be stitched together into a single file for Nginx. The order is important, so double-check the CA’s documentation. For Comodo PositiveSSL certificates, run the following:

cat domain.com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > domain.com.combined.crt

Nginx Set Up

By default, OpenSSL uses a weak 1024 byte key for Diffie Hellman key exchanges.  Let’s bump this up to 4096 by running the following command.  It can take a while to complete, so go make a sandwich:

openssl dhparam -out /etc/nginx/dhparams.pem 4096

Now let’s make Nginx’s SSL configuration a little more secure by adding the following code to the http{} block of your /etc/nginx/nginx.conf file:

http {
	...

	##
	# SSL Settings
	##

	## force modern protocols and ciphers
	## and enable ssl cache for a small
	## performance boost

	ssl_prefer_server_ciphers On;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
	ssl_session_cache shared:ssl_session_cache:10m;
	ssl_dhparam /etc/nginx/dhparams.pem;

	...
}

Now that we have the general out of the way, let’s move onto site-specific configurations. Open the configuration file corresponding to your site, something like /etc/nginx/sites-enabled/domain.com.conf.

Let’s start by adding a server block to redirect www.domain.com to domain.com, and also force HTTPS connections for everything. If www.domain.com is your main domain, simply reverse the www and non-www in the following examples.

server {
	listen 80;
	listen [::]:80 ipv6only=on;

	server_name www.domain.com domain.com;

	rewrite ^(.*) https://domain.com$1 permanent;
}

Now in your main server block for the domain, add the following:

server {
	listen 443 ssl;
	listen [::]:443 ssl ipv6only=on;

	server_name domain.com www.domain.com;

	#point to the combined certificate and key we generated earlier.
	ssl_certificate /home/domain.com/ssl/domain.com.combined.crt;
	ssl_certificate_key /home/domain.com/ssl/domain.com.key;

	#enable HSTS (in supported browsers) to make sure all subsequent
	#user requests are done over HTTPS regardless of protocol typed.
	add_header Strict-Transport-Security "max-age=31536000";

	#redirect non-canonical domain over SSL.
	#this will only work if your SSL certificate also covers www.domain.com.
	if ($host = 'www.domain.com' ) {
		rewrite ^(.*)$ https://domain.com$1 permanent;
	}
	...
}

If your server is not configured for IPv6, remove the second listen lines from the above examples. Speaking of IPv6, Nginx only wants to see a single ipv6only=on attribute per port across all your server blocks. If you have additional server blocks defined, simply omit that string from their definitions.

That’s it! Restart Nginx to apply the changes:

service nginx restart

Last Thoughts

You should now have pretty darn good SSL support! But the fun doesn’t end here!

New threats or vulnerabilities can pop up any time, to say nothing of the inevitable march of progress (advances in technology will eventually make your once great setup laughably inadequate).  Make sure you regularly apply any security patches made available to your distribution.  You should also periodically rerun the Qualys SSL Labs scan to see if any tweaks are needed to stay on top.

Posted By
Josh Stoik

New Music Video For Jennifer Hall’s “Make It Out Alive”

BBG’s art director Alex Sheyn worked nights and weekends, alongside fellow creators Jordan Balderas and Elaine Short, to create the new music video for Jennifer Hall’s new single “Make It Out Alive” from her newly-released, self-titled EP.


The video went from idea, to plan, to project, to the full-HD 4K video you see above.

With limited budget and the obvious time constraint of the project’s main contributors working on it as a side project, we couldn’t be prouder of Alex’s work on this project and are stoked to see the new video hit the web. Watch it above or on YouTube.

If you’re in Chicago, join us at the video release party this weekend (8/22). Download the EP here.

Jen Hall Cover Art

Posted By
Jason Schwartz

Bright Bright Great Announces Creative Partnership with American Needle

Bright Bright Great is proud to announce a new creative partnership with American Needle, a Chicago-area headwear manufacturer and clothier.

American Needle Hawks Snapback

BBG will be working with American Needle’s ownership and creative department to update the brand and web experience, alongside partner brands Red Jacket and Wright & Ditson, as American Needle prepares to celebrate their 100th anniversary in 2018.

American Needle pioneered the concept of sports licensing via a partnership with the Chicago Cubs in the first half of the 20th century.

American Needle Hat

American Needle and BBG

Posted By
Jason Schwartz

How-To: 8-Bit Hovers

For The Yetee’s redesign, we wanted to come up with hover styles that were unique and kept with the brand’s playful feel.

We played around with a few different options, but ultimately settled on these two 8-bit inspired hover effects.

See the Pen 8-bit Hovers by Tiffany Stoik (@tstoik) on CodePen.

Let’s walk through how they’re put together.

8-Bit Buttons

The idea behind these buttons is a pixelated side-swipe effect. When you hover, 5 bars stacked vertically slide in staggered fashion from the left. Each bar also has a square at the end of it, that flash between darker/lighter tones.

Note: In the code below, my colors have been saved as variables, and I’m only showing the styles for the desktop media query for brevity’s sake. All media query styles can be found on CodePen.

First, let’s set up our elements. These styles could work on regular anchors or buttons, but let’s use anchors for now.

<a href="#" class="btn red" title="Red">Red</a>
<a href="#" class="btn green" title="Green">Green</a>
<a href="#" class="btn blue" title="Blue">Blue</a>

Next, let’s get some basic styles for this button. Be sure to add z-index: 1 so that we can set a negative z-index on our hover panel. This will make sure it sits behind the text instead of in front of it, and that it’s not hidden behind the button’s background color.

.btn {
	position: relative;
	display: inline-block;
	margin: 0 10px;
	padding: 18px 30px;
	z-index: 1;

	border: 0; // in case this is a button element
	outline: 0; // in case this is a button element
	cursor: pointer; // in case this is a button element

	@include font-size(12);
	color: $white;
	text-align: center;
	line-height: normal;
	letter-spacing: 0.05em;
	text-transform: uppercase;
	font-weight: bold;

	// pseudo-border, so that the hover panel will cover it up on hover
	&:after {
		position: absolute;
		right: 0;
		bottom: 0;
		left: 0;
		height: 6px;
		z-index: -2;

		content: '';
	}

	&.red { background: $red; }
	&.green { background: $green; }
	&.blue { background: $blue; }
}

Now since we need five bars + five squares for the hover, we need more elements than pseudo-elements could provide. My strategy was to use a wrapper div for the whole hover, and a span for each bar, using pseudo-elements for the squares. I could have accomplished the desired effect using fewer elements, but using one wrapper and one element for each bar makes the CSS much more straight-forward.

We could add these extra elements directly in the HTML, but if you have a lot of buttons on one page, or even just a lot of other code on the page, it can get messy quickly. I opted to add the element to the DOM with javascript (jQuery to be precise) on load. This is optional and you could definitely keep the extra elements in the HTML.

// add extra elements to buttons for hover, keeps html cleaner
$('.btn').prepend('<div class="hover"><span></span><span></span><span></span><span></span><span></span></div>');

Now here’s where the complicated stuff starts to happen. Let’s style the hover panel and its children. We just want the hover panel to be positioned absolutely in the whole space of the button. Spans are going to be the vertical bars, with each span’s :after being used as the square.

Each vertical bar starts off with a different offset from the edge of the button, and has a different transition duration. To capture more of that 8-bit flavor, we’re using steps in the transition to make it less smooth.

.btn .hover {
	position: absolute;
	top: 0;
	right: 0;
	bottom: 0;
	left: 0;
	z-index: -1;
	overflow: hidden;

	span {
		position: relative;
		display: block;
		left: -15px;
		height: 10px;
		width: 0;

		content: '';
	}

	span:after {
		position: absolute;
		display: block;
		right: -10px;
		width: 10px;
		height: 10px;

		background: $white; // light-toned squares

		content: '';
	}

	span:nth-child(odd) {
		&:after { background: rgba($black, 0.35); } // dark-toned squares
	}

	span:first-child {
		left: -75px; // staggered offset
		transition: all 0.3s steps(8);
	}

	span:nth-child(2) {
		left: -45px; // staggered offset
		transition: all 0.325s steps(8);
	}

	span:nth-child(3) {
		left: -55px; // staggered offset
		transition: all 0.35s steps(8);
	}

	span:nth-child(4) {
		transition: all 0.4s steps(8);
	}

	span:nth-child(5) {
		left: -25px; // staggered offset
		transition: all 0.375s steps(8);
	}
}

Alright. Now for the actual magic. What happens when you hover? Actually not really that much. First, the spans transition to full width + offset + 1px — on some retina devices I found that without that extra pixel you could see the edge of the square. The transitions also have to be adjusted to mirror the unhover/blur transitions. So the shortest transition duration above now gets the longest transition duration, etc. You should technically be able to just adjust the transition-duration property but when I tried this, there were some browser compatibility issues, so I’m just repeating the whole transition declaration.

The only other thing going on is the little squares flashing color. We’ve got one animation, running in alternate directions for alternate squares (without prefixes for sanity). They run for the same length of time but start at different offsets.

.btn:hover .hover {
	span:first-child {
		width: calc(100% + 76px);
		transition: all 0.4s steps(8);

		&:after { animation: whiteBlack 0.3s 0s 1 forwards; }
	}

	span:nth-child(2) {
		width: calc(100% + 46px);
		transition: all 0.375s steps(8);

		&:after { animation: whiteBlack 0.3s 0.06s 1 reverse backwards; }
	}

	span:nth-child(3) {
		width: calc(100% + 56px);
		transition: all 0.35s steps(8);

		&:after { animation: whiteBlack 0.3s 0.05s 1 forwards; }
	}

	span:nth-child(4) {
		width: calc(100% + 16px);
		transition: all 0.3s steps(8);

		&:after { animation: whiteBlack 0.3s 0s 1 reverse backwards; }
	}

	span:nth-child(5) {
		width: calc(100% + 26px);
		transition: all 0.325s steps(8);

		&:after { animation: whiteBlack 0.3s 0.07s 1 forwards; }
	}
}

@keyframes whiteBlack {
	0%,
	24% { background:  $white; }

	25%,
	49% { background: rgba($black, 0.35); }

	50%,
	74% { background: $white; }

	75%,
	100% { background: rgba($black, 0.35); }
}

And that’s it for the buttons!

8-bit Social Icons

Let’s start off with some anchors. I’m using a icon font for the icons, so we just need to use the appropriate classes.

<div class="social-buttons">
	<a href="#" class="social-btn entypo-tumblr" title="Tumblr" target="_blank"></a>
	<a href="#" class="social-btn entypo-twitter" title="Twitter" target="_blank"></a>
	<a href="#" class="social-btn entypo-facebook" title="Facebook" target="_blank"></a>
	<a href="#" class="social-btn entypo-instagrem" title="Instagram" target="_blank"></a>
</div>

Basic styles. We just want a big ol’ circle and some pretty colors for the icons.

.social-btn {
	position: relative;
	z-index: 1;
	display: inline-block;
	margin: 30px 15px;
	width: 96px;
	height: 96px;

	background: $white;
	border-radius: 50%;

	line-height: 96px;
	@include font-size(45);

	&:before { line-height: inherit; } // make sure our icons are in the right place

	&.entypo-tumblr { color: $navy-darker; }
	&.entypo-twitter { color: $blue-light; }
	&.entypo-facebook { color: $blue-darker; }
	&.entypo-instagrem { color: $pink; }
}

Like with the buttons, I need more elements than I have. To get the 8-bit effect, we’re essentially going to “trace” the circle with squares and rectangles to create the pixelated look we want. For each “side”, we want three elements: one rectangle to trace the main edge and two squares to “curve” down. To keep everything neat, I’m going to use jQuery to generate 4 spans, one for each side.

$('.social-btn').prepend('<span></span><span></span><span></span><span></span>');

Now let’s style them! They’re going to start out with no opacity and scaled down to zero. When we hover, they will scale back to normal.

We’re just making this pixelated outline big enough that all the pieces fit together and outline the circle nicely. I went for a diameter of 108, 12 pixels bigger than the 96px circle. The number looked good and was divisible by 2. I knew I wanted 10px corner pieces, so from there I just had to do the math to figure out what size the long pieces should be. Each rectangle is going to be 48px on its long side and 10px on its short side. The squares are actually 10px by 16px or vice versa — wider for the top/bottom sides, taller for the left/right sides. They’re still visually 10px, we just need to make up that extra 12px to cover up any gaps where the sides meet the circle.

In testing, they were a little jittery and had some painting issues. Tossing both backface-visibility: hidden; and a perspective on them helped. The other thing that helped was transitioning only the transform on hover, and transitioning both transform and opacity on blur.

.social-btn { ...
	span {
		position: absolute;
		display: block;

		background: $white;
		opacity: 0;

		transform: scale(0);
		transition: transform 0.3s, opacity 0s 0.3s;

		backface-visibility: hidden;
		perspective: 1000;

		&:before,
		&:after {
			position: absolute;
			display: block;
			width: 10px;
			height: 10px;

			background: $white;

			content: '';
		}
	}

	span:first-child { top: -6px; } // half the diameter offset
	span:nth-child(2) { right: -6px; }
	span:nth-child(3) { bottom: -6px; }
	span:last-child { left: -6px; }

	// top and bottom pieces
	span:first-child,
	span:nth-child(3) {
		left: 24px;
		width: 48px;
		height: 10px;

		&:before,
		&:after { width: 16px; } // original width + half diameter offset
	}

	// left and right pieces
	span:nth-child(2),
	span:last-child {
		top: 24px;
		width: 10px;
		height: 48px;

		&:before,
		&:after { height: 16px; } // original height + half diameter offset
	}
}

Now let’s position the squares. Each square is a pseudo element on the rectangular span. We’re going to be moving by 10px in whichever direction is appropriate (eg: for the top piece, 10px down and 10px to the left/right).


.social-btn { ...
	span:nth-child(2):before,
	span:last-child:before,
	span:nth-child(3):before,
	span:nth-child(3):after {
		top: -10px;
	}

	span:first-child:after,
	span:nth-child(3):after,
	span:last-child:before,
	span:last-child:after {
		right: -10px;
	}

	span:nth-child(2):after,
	span:last-child:after,
	span:first-child:before,
	span:first-child:after {
		bottom: -10px;
	}

	span:first-child:before,
	span:nth-child(3):before,
	span:nth-child(2):before,
	span:nth-child(2):after {
		left: -10px;
	}
}

After all that, the hover is pretty simple. Grow it!

.social-btn:hover {
	span {
		opacity: 1;
		transform: scale(1);
		transition: transform 0.3s;
	}
}

And that’s how you make 8-bit hovers! Be sure to check out The Yetee, where you can see these hovers in action, and lots of other awesome stuff.

Posted By
Tiffany Stoik

New Work: Lichter Realty

BBG is excited to announce the launch of Lichter Realty’s new website!

A family owned-business for more than 30 years (and our neighbors!), Lichter Realty isn’t just focused on revitalizing Chicago’s northwest side, but on expanding their family with every new tenant they get.

As part of this project we refined Lichter’s branding and color palette, designed a new art direction and web presence, and did photo shoots for their team and 10 of their spaces.

Lichter seal

Lichter homepage

Lichter properties

Lichter property search

Lichter icon sets

mobile lichter 2

Lichter dance space

Lichter restaurant

Lichter auto shop

Ray Lichter & Sir Charles

Sir Charles looks up Sir Charles done

Posted By
Jason Schwartz

BBG Tips: Keep WordPress Tidy

WordPress is kind of magical. It gives site operators the power to quickly and effortlessly extend functionality, tweak design, and preview and post new content.

However, this power of immediate evolution – a key feature that has made so many insightful blogs about cats sleeping in weird places possible – can, over time, lead to clutter, increased hardware costs, and even security vulnerabilities.

Organized Desk

Keeping WordPress tidy is as important as keeping your workspace clean.

Thankfully, a little bit of spring cleaning will go a long way. (Even if you don’t get around to it until the end of summer.) There are two areas to focus on:

Disk

First and foremost, conduct a quick census of the plugins installed on your site. If you notice any that aren’t actually being used, deactivate and delete them. All plugins contribute to the overall resource demands made of your server, so at best, unused plugins are needlessly slowing things down.

More importantly, plugins also add a lot of code to your site, code which may contain bugs or security weaknesses that a hacker would love to leverage against you.

Themes are another area that can grow quite cluttered over time. Even though inactive themes won’t contribute one way or another to your site’s performance, you should still delete them from the server as they might contain exploitable security vulnerabilities.

Byte for byte, orphaned thumbnails from uploaded images comprise the most wasted disk space on the average aging blog.

Every time an image is uploaded to WordPress, anywhere from a handful to a boatload of differently-sized thumbnails are generated and saved to the server. The precise dimensions of the thumbnails vary from theme to theme, so for sites that have switched designs, this can lead to a lot of images cropped at resolutions that will never be accessed again.

The plugin Force Regenerate Thumbnails will take care of this, deleting all existing thumbnails, and regenerating only those that are actually required by the current theme. Depending on how many images you have, this can take a while, so go make a sandwich if you’re hungry.

Data

Your database, too, can easily start to look like the dark recesses of an attic, full of tangled and broken holiday decorations, old clothes, and haunted chests. The largest culprit here is usually post revisions.

WordPress maintains a history of all changes made to all posts.

This is nice because it allows you to review any changes you’ve ever made and rollback to a prior version at any time.  But this also generates a lot of bloat, particularly if you can’t decide between desert or dessert or desert or dessert.

Thankfully, this is something you can fix automatically by capping the number of revisions to some sane value. You can do this by adding the following to your wp-config.php file:

//specify the max # of revisions, 3 in this example
define('WP_POST_REVISIONS', 3);

The WP_POST_REVISIONS setting is not enforced retroactively. To remove or prune excessive revisions for existing posts, you can use a plugin like Thin Out Revisions.

The trash can also be an area of database bloat. When you delete a post, it is moved to the trash. Just like the trash on your laptop or the trash in your kitchen, items will linger forever and ever until someone bothers to empty it.

You can automate this task in WordPress, at least, by adding the following to wp-config.php:

//specify the # of days before emptying, 5 in this example
define('EMPTY_TRASH_DAYS', 5);

One last area of data bloat is one that can be really bad on some sites, and nonexistent on others: transient data.  WordPress includes an API for temporarily storing arbitrary key/value pairs for later retrieval.

Most often, transient data is used to cache results that would otherwise take a while to generate, such as a response from another server (for example, a Twitter feed) or the end result of a really convoluted query (like: find all posts published on a Wednesday about apples or oranges but not mangoes…).

By default, WordPress stores these data in the wp_options table.  Though each piece of information is given an expiration, WordPress does not do any automatic garbage collection.

Transient data is only removed if and when it is requested (after expiry).

If a given transient key is not reused, the data will outlive us all.  Fortunately, you can keep expired transient data in check with the help of the aptly named plugin Delete Expired Transients.

That’s it!  Happy cleaning!

Posted By
Josh Stoik