WordPress Plugins : Demo Data Creator

Here is a useful plugin for all of you, WordPress developers – Demo Data Creator.   It generates a whole lot of test / demo data and populates your WordPress site with it.  No more lengthy copy-pastes of Lorem Ipsum into posts and pages, single user (hi admin) installations, and senseless “foobar” and “foobar2” categories.  Now you can populate your test or development environment with lots of data to help with previews, and all those issues around search, pagination, and things like that.

demo-data-creator

If you’d rather avoid the plugin and automate this kind of work yourself, make sure to have a look at WP-CLI – command line interface for WordPress, which, among others, has the “wp post generate” command.

Emails, WordPress, and lots of Archives

I’ve been running this blog for a very long time now.  The Archives page links back to all the months and years (all the way to the first post back on October 21, 2001) of all kinds of posts – random rants, movie reviews, technical posts, and day summaries.  But who does read the archives ever, right?

Well, if you are running a WordPress site with lots of content, and you want to rediscover some of your old gems, there is an excellent plugin that helps with that – “This Day in History“.  I have a widget, powered by that very plugin, both on the front page of the site (showing posts from the same day in previous years), and on every post page (showing posts from the same day of the post in different years).

Today I found this short post about email and Microsoft Outlook:

There was a time, when I used to love email.  I loved receiving email, and reading it.  Replying to email.  Or just writing up some new email.  Occasionally, forward email.  I loved searching through email.  Or categorizing it.  Or archiving email.  I loved quoting email.  And I loved email with attachments.  But now, I pretty much hate all of that.  Thank you, MS Outlook.

Which made me think of the IT Crowd TV series, the very first episode of the very first season, where Jen was going through the interview:

I’ve always been a big fan of IT Crowd, in particular for its accurate take on the corporate culture.  Obviously, I thought of myself more like the Roy character, not Jen:

Given that the post was written in 2012, and this episode came out in 2006, I was probably mocking it, but I don’t remember for sure. Anyways, it’s fun.

Oh, and by the way, if you were wondering what’s a better email client, here is the post just for you.

28 Ways to Secure WordPress Website

28 Ways to Secure WordPress Website covers, as the title says, quite a few ways to make your WordPress website more secure.  There is no absolute security, and there are always more that you can do, but this is a good start.  Apart from all the useful advice, the article also tells you why you should care:

“Why would anyone hack my site?” – you ask

Let’s be clear. Your site is likely not special. Unless your firm’s name is CNN.

The fact is that most – or the great majority, rather – of attacks are automated. This means that various bots (pieces of software) developed by hackers crawl the web and look for vulnerable sites.

Then if they’re successful, the site gets added to the hacker’s portfolio, so to speak, and can be used for various purposes.

In other words, your site by itself is no special, but 10,000 sites just like yours is pure gold for a hacker. Such a network of hacked sites can be used for things like black hat SEO, mass email sending, database scraping (to get your users’ personal info), and so on.

You really shouldn’t feel overly safe just because/if you run a relatively small website.

Hackers don’t discriminate.

WordPress Plugin : Ultimate Social Media

If you are one of those dinosaurs, who still prefer to post content to your own web space and then share it on social media (much like yours truly), then here’s the Ultimate Social Media WordPress plugin (you are using WordPress, right?) that helps will those buttons, sharing, animation, and more.  You can even choose how your site’s buttons will look like from 16 different designs.

social buttons

Bad project

CommitStrip nails one of the ways of getting into a bad project …

bad project

I remember reading an interview with Matt Mullenweg (though can’t seem to find a reference now), where he said that this sort of thing happened with Automattic.  People were asking them for commercial support, but they didn’t want to do it, so they started with an insane amount of like $5,000 per month and all of a sudden found themselves with a queue of people outside.

And they were not alone, of course.

Adventure in composer private repositories

First of all, I would like to take this opportunity and wish composer a happy birthday and many more years to come.  It’s been five years, and the world of PHP has changed so drastically that not many people remember how it used to be before.

I would have completely missed the birthday if it wasn’t for all the Google searching I did while working on a weird problem.  But before I get to the problem, let me set the scene.

The big part of composer success is Packagist.org – the repository of almost 100,000 packages (93,572, according to statistics, as of this writing, to be precise), which help one to solve pretty much any problem that PHP can be used for.

As good as the Packagist is, there is often a need for a repository or a package elsewhere.  Whether it’s a commercial library, or sensitive corporate code, having an ability to store it outside of public eye and handle with the same ease and the same tool as the rest of the dependencies is a very welcome feature.

Now we are getting closer to what actually happened.  A while back, I’ve setup deployment and development process for WordPress-based projects.  WordPress doesn’t support composer natively, but there are ways to make it work.  Huge thanks here goes to Roots.

So.  The composer.json file was filled with additional repositories and requirements which told composer where from to fetch things, and where to install them.  Here’s an example:

"repositories": [
    {
        "type": "package",
        "package": {
            "name": "wordpress",
            "type": "webroot",
            "version": "4.4.1",
            "dist": {
                "type": "zip",
                "url": "https://github.com/WordPress/WordPress/archive/4.4.1.zip"
            },
            "require": {
                "fancyguy/webroot-installer": "1.1.0"
            }
        }
    },
    // ...

This got especially useful, when we need to work with commercial plugins, which we couldn’t push to our public repositories, and which we didn’t want to re-distribute with every project.

So far so good. Fast-forward to a few month ago. We are setting up similar development and deployment process, but now for CakePHP-based projects. Things are much easier, since CakePHP 3 natively supports composer for the application itself and for its plugins.

But we still have the need for private repositories here and there, so we follow the same setup as we did for WordPress. This week, we had an unexpected roadblock, which wasn’t making much sense to me. When trying to pull a CakePHP plugin from a private repository, we’d get a nasty exception like this:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing qobo/cakephp-test-foo (1.0.1)
    Loading from cache


                                                                                                                                              
  [RuntimeException]                                                                                                                          
  Unable to get primary namespace for package qobo/cakephp-test-foo.                                                                          
  Ensure you have added proper 'autoload' section to your plugin's config as stated in README on https://github.com/cakephp/plugin-installer  
                                                                                                                                              

This was confusing. First of all, I’ve never seen this error before. Secondly, I’ve read the README and had the autoloader section in the composer.json as instructed. Thirdly, very similar plugins were working fine.

Long story short, the issue wasn’t related to whether or not the GitHub/BitBucket repository was private or public. It was related to how the repository was configured in the composer.json. Reading and re-reading composer documentation about Repositories finally helped.

You can have a look at our test setup:

CakePHP plugin installer requires the autoload section in composer.json.  But, when the repository is of type “package“, for some reason, the autoload section is ignored altogether.  The RuntimeException “Unable to get primary namespace for package” is thrown by cakephp/plugin-installer (src/Installer/PluginInstaller.php line 274).  The problem is not actually in the cakephp/plugin-installer, but somewhere in the composer.  Maybe it’s intentional or maybe it’s not.  I didn’t have the time to investigate and understand it further.

Switching the repository to type “vcs” fixes the problem.  It also simplifies the composer.json file and removes the need for multiple version definitions, as now composer is using BitBucket/GitHub API to fetch available versions.

WordPress 4.5 “Coleman”

WordPress 4.5 “Coleman” – the newest WordPress version has been released (I’ve just upgraded).  Some of the changes included in this release are:

  • New and improved user interface for editing links in posts and pages.
  • More Markdown-like shortcuts for formatting text (now with code and horizontal lines).
  • Logo support in themes
  • Much improved image optimizations (initially expected in WordPress 4.4)
  • Better embed templates
  • Update for underlying libraries, such as jQuery, Backbone, and Underscore.

If you already manage a WordPress website, you’ll find the notification of the update in your admin area.  If not, then go and download it.

WordPress Plugin : Typecase Web Fonts

Disclaimer: I’m not much of a fonts guy, but once in a while I just want to be.

I was reading the “Best Practices for Designing a Pragmatic RESTful API” article, when I realized I liked the font it was written in very much.  I liked it so much that I immediately wanted to have it on my blog too.  Chromium Inspector tool helped identify it as Ubuntu font family.

I have no problem editing WordPress themes’ CSS files, but I prefer to avoid it whenever possible.  So a quick Google search later I found this blog post, which describes how to customize fonts in the Twenty Fifteen theme, which is coincidentally what I’m using currently.

The blog post recommended Typecase Web Fonts plugin.  I installed it and started playing around with it, and I have to say it’s pretty amazing.  Basically, it provides a font search tool in the WordPress admin.  Once you find the font, it shows you the preview text and some font details.  You then add CSS selectors on which you want this font to apply.  It took me literally 3 minutes to figure it all out.  You can even add multiple fonts.  For example,  since now I had sans-serif font for the blog content, I wanted to use a serif font for the headings – boom! – and I have Roboto Slab font to compliment Ubuntu.

The plugin is so easy to use and is so handy that I think we’ll be using it at work now too.  Check it out.

Random fonts and colors for each WordPress blog post

Here is an interesting web design idea that adds uniqueness to the website : use a random font for post titles, and use random color schemes for each post.   To hell with consistency you say?  Well, apparently, being random is being consistent too.

Picked up the thought from this blog post.