Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/V-gDBbmoWVk/redesigned-leeds-united-badge-has-outraged-fans

Leeds United has nearly hit its centenary, so to celebrate, the club decided it was time to redesign its badge (above). Despite referencing the 'Leeds Salute', however, the new crest has not been well received by fans.

Unveiled today, Leeds United's new crest took six months of work to complete and involved consultation with more than 10,000 people. For the uninitiated, the 'Leeds Salute' referenced in the new crest is a gesture used by fans on match days, where they place their right hand on heart and sing the club's song Marching on Together.

The redesigned badge is the latest in a series of efforts by the club to re-engage fans and the wider community. Leeds United isn't the first sports organisation to rely on a rebrand to boost interest, of course. Earlier this year, Formula 1 changed its logo to get more people involved.

Leeds United managing director, Angus Kinnear, said “updating the crest is not a decision we have taken lightly, but we are proud to have a new crest that is authentic to Leeds United and honours the quality and loyalty of our fans. It is a symbol of ‘strength in unity’ and a proud expression of the club’s identity and history.”

Currently, however, the only thing Leeds United fans are united by is their dislike of the new crest. Plenty have taken to social media to voice their despair, with some taking aim at how the emblem can be modified to represent other teams. (A popular one sees a Newcastle supporter punching a horse.)

One element that's caused anger and confusion is the crest appears to be covering itself up. If a fan or player does the 'Leeds Salute', of course, by its very nature the gesture obscures the badge – but when it comes to design, blocking your team's badge is a peculiar way to show pride.

With a petition to stop the new badge from being implemented having already racked up over 10,000 signatures, it remains to be seen whether the club holds its ground or gives in to fan pressure.

Related articles:

Photography book celebrates the joy of footballThe 20 posters of the FIFA World Cup5 great EPL football stadium illustrations

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/FAHDBL31eIM/power-a-blog-using-the-wordpress-api

Over the past few years, the development of a REST API for WordPress has opened new doors for developers. Developers who had previously been limited to writing a WordPress-powered project in PHP now have more flexibility and control in how they can approach the technology stack of their website-to-be.

This means it’s possible to retain all the advantages of the brilliant WordPress control panel, which is made extremely flexible by popular WordPress plugins such as Advanced Custom Fields, and have a completely custom built frontend that only interacts with WordPress when it needs to.

Download the tutorial files

In this WordPress tutorial we’ll be exploring how to implement the WordPress REST API into a simple blog app, which is currently using a local JSON file as its data source, and is built as a single-page application (SPA) using the popular JavaScript framework Vue.js. This will involve the implementation of Vuex, which we’ll use to store the data we request from a WordPress using a combination of its action and mutation methods.

Once completed, you should have created a lean, simple SPA, which has all the reactivity of Vue.js, while displaying posts retrieved from and managed by WordPress.

01. Set up workspace and dependencies

First things first, you should download the project’s files and open them in your preferred editor. 

In the console, cd into website-template and run the command below to install the project’s node dependencies (if you don’t have Node installed, do that first). We’ll be working purely in the src directory from here on out.

02. Install Vuex 

Next, using the command below, we’ll install Vuex, which is a state management pattern and library for Vue.js applications. This will act as a central information store for all Vue components that depend on the data we receive from WordPress API. For developers familiar with React, Vuex is heavily inspired by Flux.

03. Start development server

In the console, run the command below to start the development server. This will compile the Vue.js project as it currently stands and assign it to a URL so you can access it. This is usually localhost:8080.

One big advantage this brings is live reloading, so once you make changes to the app and save, the page in your browser will update itself without the need to manually reload.

04. Create Vuex store

In src, create a directory called store and within it a new file called index.js. This will be where our Vuex store will be defined. Though before we get to that, we need to first make sure our Vue.js app is aware of its existence. To do this, open main.js and import the store and include it as a dependency, as in the snippet below.

05. Create store scaffolding and install Axios

To help us simplify the AJAX requests our store will be making to WordPress API, we’ll install Axios, which is a Promise-based HTTP client. To do this, open a separate console window, navigate to the website-template directory and run npm install axios — save.

Next, let’s start to scaffold the store by instantiating a new empty Vuex store object. At the moment, it isn’t doing anything, but at least Vue should be aware of it.

06. Create posts state

In Vuex, the state object holds application info, which in this case will be the WordPress post data we’ll grab using the API. Within this object, create a new property called posts and assign it a value of null.

07. Create getPosts action

In Vuex, actions are the main way in which asynchronous requests are handled. These are typically methods defined in the store, which can then be dispatched as required by the app.

In the empty actions object, let’s define one where if our posts state is still null, axios is used to perform an AJAX request to the WordPress API and return a list of posts. Once we’ve received a positive response, we’ll then resolve the promise and commit the posts using the storePosts mutation.

08. Create storePosts mutation

Another concept introduced by Vuex is mutations, which are also typically methods defined in the store. Mutations are the only way to change state in a Vuex store, which allows state to be easily tracked when debugging.

In the empty mutations object, let’s define the storePosts method we referenced in the previous step and make it override the post property in the state object with any data the mutation receives as payload.

09. Trigger getPosts action on load

We’ve created the action and mutation methods that grab posts from WordPress API and commit them to Vuex state, but now we need to actually trigger this process somewhere. In the top level Vue.js component App.vue, add the snippet below.

created() is a lifecycle hook that triggers code as soon as the Vue component is created on load, while the use of the global $store variable allows us to access the contents of our Vuex store and dispatch the getPosts action from step 7.

10. Update attribute paths

The Vue DevTools extension gives you the power to debug your Vue.js app

If you’re working in Chrome or Firefox and have the Vue.js DevTools extension (if not, I recommend that you do as it’s very useful), you should now be able to see the loaded WordPress posts in Base State under the Vuex tab. 

Back to the app, in /components/posts/posts.vue, the template HTML needs to point to this data, so let’s tweak a few of the attribute paths.

11. Update v-for loop

In the posts component, there’s a Vue.js directive in use called v-for. This loops through all posts and for each one prints an instance of the post component, displaying them in a list. 

We need to update the path passed to this directive as it’s still using the local dummy test data. Update the v-for directive to the snippet below in order to point to our stored posts in the Vuex store.

12. Do some housekeeping

A list of the WordPress posts should now be displaying. As we're no longer using the local post data, let's delete src/data. Then in the posts component, remove the posts: postData.data property in the components local data store and then the postData import.

13. Fix post author

You may notice that for each post the author is showing up as a number. This is because the WordPress API returns an author ID, rather than a name. We need to use this id to query WordPress for the full author information. Let's start by creating a place to store this in our Vuex store, alongside our post info, in store/index.js.

14. Create getAuthors action

As with posts, we'll create an action in /store/index.js to trigger an AJAX request to query WordPress API. Once a successful response is received, the promise will then resolve and trigger the storeAuthors mutation, which we'll create next.

15. Create storeAuthors mutation

Within the mutations object of the Vuex store, create the storeAuthors mutation using the snippet below. Like with storePosts from step 8, this takes the payload its passed and sets it as the value of the authors property in our store's state.

16. Trigger getAuthors on load

We need to get the author info from WordPress as soon as the app begins to load. Let's amend the top level component App.vue again and dispatch the getAuthors action in the same created() lifecycle hook as the getPosts action.

17. Create getUserName method

Now we're querying WordPress for author information on load, all we need to do is define a method in our posts component which lets us pass an author ID and get a name in return. Copy the snippet below into the posts component's methods object, below the existing getSinglePost method.

18. Call getUserName method

Now we just need to call getUsername. Still in the posts component, in the template, replace the author attribute’s reference to post.author so it reflects the snippet below. The author’s name should now be correctly displaying for each post.

19. Blog loading

As we’re loading the post data asynchronously, there is a moment before the request completes where the application is empty. To counter this, we’ll implement a loading state that's active until the blog is fully populated. In the posts component, paste the snippet below just after the opening <script> tag to import the icons we’ll be using.

20. Add icon to components list

Next, still within posts, add a reference to icon in the components objects. This makes the posts component aware of our recently imported icon component.

21. Create loading elements

We now just need to add the loading elements to the posts template so it shows up on the page. Firstly, wrap the second div in the snippet around the two divs with the v-if directives to make sure no posts show up until loading is complete.

Then add the first div from the snippet above it. This contains the loading icon and a v-if directive, which means it will only be visible until the point where the app is fully loaded. Once done, loading should now be implemented.

22. Update single post attribute paths

The only thing left to do is to make sure single posts are correctly set up so they are using the WordPress post data in the Vuex store. The first step is to update the attribute paths in the posts component template within the v-if="this.type === 'single'" div, which handles the display of single posts.

23. Refactor getSinglePost method

We also need to refactor the posts components getSinglePost method. It needs to return a promise that dispatches the getPosts action. In the follow up then function, we'll search the Vuex store's posts for an entry with a slug matching the one passed in the URL. If found, we'll copy the data to our component's local state and resolve the promise. If it isn't found, the promise will be rejected.

24. Refactor posts created() hook

Next, we need to refactor the created() lifecycle hook in the posts component. If we're needing to display a single post, the hook should call the getSinglePost method from the previous step, and if its promise is rejected, send the user to the 404 'page not found' page. This is to account for scenarios where users enter a non-existent post slug in the URL.

25. Add v-if directive

The final step is to add the snippet below to the post component within the v-if="this.type === 'single'" div in the template. This directive means the post will only display when the local post data made available by the getSinglePost method is populated. This is to stop Vue from prematurely rendering the component and thus causing errors.

26. Build the app

Now with everything working, in the console, cancel the npm run dev command or open a new console and run the below command to generate a production ready version to upload to your own server. This will appear in the dist directory.

This article appeared in issue 268 of Web Designer, the creative web design magazine – offering expert tutorials, cutting-edge trends and free resources. Subscribe to Web Designer now.

Read more:

32 best free WordPress themes10 top WordPress resourcesThe 14 best free blogging platforms

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/xlnNo1XEq5g/

If you use WordPress, a big change is coming. The impending release of version 5.0 will bring along with it the new Gutenberg editor. It’s poised to become a major step up in terms of the ability to customize the look of your content in a default WordPress installation.

It’s a very different experience in that this new editor will break content sections down into “blocks”. Blocks will enable you to, say, add a full-width image right in the middle of a blog post. Or you might build your own custom blocks that allow users to implement different layouts.

In short, Gutenberg brings a little bit of what page builder plugins have been doing for years – without some the fancier bells and whistles. It’s a more unified way to mix text and multimedia into your content. And it promises to be a much more user-friendly and visual way to do things.

This evolution has brought about a ton of debate and, naturally, a good bit of concern. WordPress boasts an enormous market share and designers/developers/users are rightfully wary of such a big change. The team responsible for Gutenberg is taking steps to assuage concerns, but the bottom line is that we won’t know the full effect of things until the official release.

While WordPress 5.0 will be released sometime in 2018, you can try Gutenberg now in the form of a plugin. If you want to get a behind-the-scenes look, check out the 2017 State of the Word Address, which features a live demo.

Gutenberg is something that all of us should be aware of. In order to take full advantage of the new editor, there are some steps we’ll have to take. Plus, some may decide not to use it at all as the “classic” editor will still be available as a plugin for the foreseeable future.

With that in mind, let’s take a look at how to prepare for the big change. We’ll look at the considerations and share some helpful resources that can guide you along the way.

The Decision to Switch (Or Not)

Major changes to any software usually lead a healthy portion of users to avoid upgrading. Operating systems are a great example as many larger companies are still a version or two behind. Of course, for security and compatibility reasons, it’s never recommended that we run outdated versions of WordPress. So, in that way, upgrading to 5.0 isn’t really optional.

But since we can decide to continue using the classic editor via a plugin, the decision of whether to utilize Gutenberg is one we’ll all have to make. Depending on the setup of your site, switching could be kind of a big deal. Developers will have to consider:

Any potential complications with existing themes, plugins and customizations.
If a client is responsible for managing content, some training may be required.
The increased demand for customer support, should something unexpectedly break.
If you’re already using a page builder plugin, does it make sense to change?

One thing is for sure, it will be a process for many of us. For mission-critical sites, it might not be a great idea to implement changes without testing them first within a development environment. If you manage multiple sites, that can be a whole lot of work.

I would suspect that some developers would choose to hold off on switching for some time – at least for existing sites. On the other hand, if a site could really benefit from the added capabilities of Gutenberg, then it might make sense to take the plunge.

Your Theme and Gutenberg

By default, your theme should work with Gutenberg just as it does now with the classic editor. But you do have the ability to add in extra styling for the various available blocks. For example, the image block places code similar to the following into a published page:

<figure class=”wp-block-image”><img src=”your-image.jpg”></figure>

So, you could provide some CSS for .wp-block-image to jazz things up a bit – although it’s not required.

But where the editor really holds promise with themes is the ability to create your own custom blocks. Think of the potential to add site-specific layouts and content directly into the editor. Then add in the fact that you can pass styles on to the back end of your site, providing users with a more accurate WYSIWYG experience. This could be quite the game-changer when building a site. Check out the resources section below to learn more.

Plugin and Customization Compatibility

This is where much of the concern lies with both developers and site owners. Untold numbers of websites have had their back end customized in some shape or form. And just about everyone with a website that runs on WordPress uses plugins. So yes, there is the potential for something to go wrong.

However, this is an area where the folks behind-the-scenes are really working diligently. Backwards compatibility has always been a key part of WordPress and that doesn’t figure to change now. And the larger plugins out there all have an incentive to make sure that their products work with the new editor. There’s simply too much to lose for everyone involved for this not to work.

But, as mentioned earlier, testing everything out in a development environment is the best way to know how Gutenberg will affect the setup of your site. From there, you can figure out what (if any) issues you might need to clean up.

While it certainly sounds like most configurations will work just fine, there is always that chance that something doesn’t play nice with the new editor.

Client Considerations

One other area of interest is how Gutenberg may affect your clients. The way it stands, not everyone knows that an entirely new editing experience is on the way. Casual users probably aren’t paying close attention, even though recent WordPress upgrades have mentioned the coming changes. So they may be in for a bit of a shock when 5.0 drops.

But this is where we can take it upon ourselves to make a difference. Engage clients and let them know that Gutenberg is on the horizon. Provide a general background and maybe a few user-friendly links that might help them become more familiar with the UI.

A little bit of education now can (hopefully) save you from a few panicked calls later on.

Resources

As Gutenberg continues to evolve, there are more valuable resources coming out to help you learn and prepare:

Gutenberg Handbook
There is a process behind creating custom blocks. To learn more, check out the Gutenberg Handbook. It takes an in-depth look at how the editor works and provides some tutorials on block creation.

Gutenberg Boilerplate
Ahmad Awais has created a boilerplate for building custom blocks for Gutenberg. He has included a few different scenarios that can serve as a great learning tool.

Gutenberg Theme
If you want to see an example of how a theme can take advantage of Gutenberg, take a look at the free Gutenberg Theme over on GitHub. It was built by Tammie Lister, who is the head of the team working on the new editor. The theme isn’t necessarily meant for a production environment, but provides a useful playground for interested developers.

WordPress Gutenberg Guide
Codeinwp has put together an illustrated guide that will get you familiar with the basics of Gutenberg, along with some more advanced tricks.

Development Updates
The official source for Gutenberg Development Updates is a great way to keep up with new features, along with thoughts from the developers themselves.

Block Party

The full release of Gutenberg will be a watershed moment in the history of WordPress. And, overall, it looks to be a change for the better. There will certainly be an adjustment period and some bumps in the road. But that is only more the reason to dig in now and see how everything works.

You’ll get a sense of how you might benefit from Gutenberg and valuable knowledge on how to handle the transition ahead.

Original Source: https://www.sitepoint.com/an-introduction-to-node-js/

So you’ve heard of Node.js, but aren’t quite sure what it is or where it fits into your development workflow. Or maybe you’ve heard people singing Node’s praises and now you’re wondering if it’s something you need to learn. Perhaps you’re familiar with another back-end technology and want to find out what’s different about Node. […]

Continue reading %What Is Node and When Should I Use It?%