Donald Trump told companies they will have to shift manufacturing to the U.S.

Donald Trump Tells Auto Makers They ‘Have to Start Making Things Here Again’

The president-elect called automotive trade between the U.S. and Germany a ‘one-way street’

President-elect Donald Trump told companies they will have to shift manufacturing to the U.S. in order to do business here, in a series of comments indicating a tough posture toward U.S. trade partners.
“Car companies and others, if they want to do business in our country, have to start making things here again.

Installing WordPress Locally on Your Mac With MAMP

Installing WordPress Locally on Your Mac With MAMP

What is MAMP?

MAMP stands for Macintosh, Apache, MySQL, and PHP. MAMP is an application you can install on your Mac which allows you to have access to a local PHP server and MySQL server. Essentially, MAMP gives you all of the tools you need to run WordPress on your machine, for development and testing purposes. You can accomplish this in different ways, but the other ways aren’t nearly as simple (see MacOS_X_Local_Mirror for the long, manual version of installing PHP and MySQL on your Mac).

Step 1: Installing MAMP

Before you can install MAMP on your Mac, you’ll need to download it from the MAMP website. MAMP requires that your Mac be running Mac OS X 10.6.6 or later.

Once the MAMP download is complete, double-click the MAMP disk image (it should be something like MAMP_2.0.3.dmg), and you should get a MAMP window pop up. Drag the MAMP folder (not MAMP PRO – we’ll save that walk-through for another time) to the Applications folder.

Step 2: Basic MAMP Settings

Now that you’ve got MAMP installed on your system, launch (located at /Applications/MAMP/

While you’re editing settings, MAMP might prompt you for an administrator password. This is required because MAMP needs to run two processes: mysqld (MySQL) and httpd (Apache), and depending on the settings you set for those processes, you may or may not need to input your password.

Once you open MAMP, click the Preferences button. Next, click over to “Ports.” The default MAMP ports are 8888 for Apache, and 8889 for MySQL. If you use this configuration, you shouldn’t get asked for your password, but you’d need to include the port number in the URL (localhost:8888). If you’d like to leave the port number out of the URL, change the Apache port to 80. The downside of using port 80 as your MAMP Apache port is that you’ll always be asked for your password.

Lastly, on the Web Server tab, you’ll need to set a document root. This is where all of your files are going to be for your local web server. An example of a document root is /Users/USERNAME/Sites/wordpress/.

Once you’re done editing all of the settings, hit OK to save them.

Step 3: Starting MAMP Servers & Creating The Database

To start the MAMP Apache and MySQL servers, simply click “Start Servers” from the main MAMP screen. Your MAMP servers have now been started.

Once the MAMP servers start, the MAMP start page should open in your default web browser. If not, click on “Open start page” in the MAMP window. Once that’s open, select phpMyAdmin from the webpage.

Under “Create new database”, enter in a database name such as “wordpress”, and press “Create.” No need to choose an option for “collation” : it will automatically be assigned by MySQL when the database tables are created, during the WordPress installation.

Step 4: Downloading and Installing WordPress

Now it’s time to download WordPress. Once you’ve downloaded and unzipped the WordPress download, open up the “wordpress” folder. Click and drag all of the files from the wordpress folder to your MAMP document root (I use /Users/USERNAME/Sites/wordpress/).

Others with the default MAMP install should rename and drag the folder to the htdocs folder, located under /Applications/MAMP. Then in the browser, go to localhost:port/folder_renamed to run the install. For example, in the default MAMP install, if the folder was renamed wordpresstest, go to localhost:8888/wordpresstest.

Lastly, we’ve got to run WordPress’ famous 5-minute install. Visit your local site (localhost:port or localhost:port/wordpress), and enter the following information into the database setup form:

Database Name: wordpresstest
User Name (database): root
Password (database): root
Database Host/server: localhost
Table Prefix: wp_
Note that the default Database Name is “WordPress” and that you will need to change the Database Name to the name you entered into PHP Admin (in this case, “wordpresstest”). If you have multiple WordPress sites on your local machine, each of which is using its own database, you will need to make the Database Name in the WordPress configuration consistent with your second (or third or fourth) Database Name.

Once that’s complete, enter a blog name and email address, and you’re ready to use WordPress on your Mac.

Offline strategies come to the Service Worker Cookbook

Offline strategies come to the Service Worker Cookbook

By Salva Posted on October 19, 2016 in Featured Article and ServiceWorkers is a compendium of common and uncommon Service Worker use cases including push examples, usage patterns, performance tips and caching strategies.

Service Worker Cookbook recipes are presented as playgrounds or labs, with fully functional client-server setups, where you can learn and experiment with results using in-browser developer tools.

Still, the cookbook is far from comprehensive, and we realised it lacked some basic materials and user feedback mechanisms. Today, I’m proud to announce some changes to the Service Worker Cookbook starting with a new section about caching strategies.

Caching Strategies

Caching strategies includes recipes that demo several ways of serving content from a service worker. The recipes follow an identical layout in which two iframes are displayed side by side. Both show an image element pointing to the same online picture.

The first iframe is not under service worker interception, so the picture always displays fresh content from the server. In contrast, the second iframe is controlled by the service worker and the content is served according to the implemented cache strategy.

Layout for offline recipes: two iframes, the first controlled and the second not.

Picture content changes on the server every 10 seconds and you have a button to refresh both iframes at the same time and compare what happens to the images.


Some of the caching strategies are taken from an inspiring article from Jake Archibald’s “The offline cookbook” and others are homegrown.

Cache only

The most basic example: With cache only, requests will never reach the network. Instead, they will be served by the service worker from a local cache.

self.addEventListener(‘fetch’, function(evt) {

function fromCache(request) {
return (cache) {
return cache.match(request).then(function (matching) {
return matching || Promise.reject(‘no-match’);
In this implementation, cache-only assets are stored while installing the service worker and they will remain there until a new version of the worker is installed.

self.addEventListener(‘install’, function(evt) {

function precache() {
return (cache) {
return cache.addAll([
You can use the cache-only strategy for your site’s UI related assets such as images, HTML, sprite sheets or CSS files.

Cache and update

This slight variation on the cache-only strategy also serves assets from a local cache but it also sends network requests for updated versions of the assets. The new content then replaces the older asset in the local cache.

self.addEventListener(‘fetch’, function(evt) {

function update(request) {
return (cache) {
return fetch(request).then(function (response) {
return cache.put(request, response);
With this cache and update strategy, there comes a point when your assets are no longer synched with those online, but they will be synched upon a second request, which roughly translates to a second visit.

It is totally fine to use this strategy when delivering independent, non-critical content such as avatars or icons. Avoid relying on this strategy for dependent assets (such a complete UI theme) since there is nothing ensuring that the assets will update as needed at the same time.

Cache, update and refresh

Another twist on the previous strategy, now with a refreshing ingredient.

With cache, update and refresh the client will be notified by the service worker once new content is available. This way your site can show content without waiting for the network responses, while providing the UI with the means to display up-to-date content in a controlled way.

self.addEventListener(‘fetch’, function(evt) {

function refresh(response) {
return self.clients.matchAll().then(function (clients) {
clients.forEach(function (client) {
var message = {
type: ‘refresh’,
url: response.url,
eTag: response.headers.get(‘ETag’)
This is especially useful when fetching any kind of content. This is different than the previous strategy in that there is no need for a user to refresh or visit the site a second time. Because the client is aware of new content, the UI could update in smart, non-intrusive ways.

Embedded fallback

There are situations in which you always want to always display something to replace content that’s missing for whatever reason (network error, 404, no connection). It’s possible to ensure always available offline content by embedding that content into the service worker.

self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(networkOrCache(evt.request).catch(function () {
return useFallback();

// Dunno why this is shown as the actual SVG in WordPress but it looks awesome!
// You can see the source code in the recipe.
” +
‘ ‘ +
‘ ‘ +
‘ ‘ +
‘ ‘ +

function useFallback() {
return Promise.resolve(new Response(FALLBACK, { headers: {
‘Content-Type’: ‘image/svg+xml’

In this recipe, the SVG which acts as a replacement for missing content is included in the worker. As soon as it is installed, fallbacks will be available without performing new network requests.

Network or cache

Service Workers place themselves between the client and the Internet. To some extent, they allow the developer to model their ideal network behaviour. This strategy exploits/enhances that idea by imposing time limits on network responses.

self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(fromNetwork(evt.request, 400).catch(function () {
return fromCache(evt.request);

function fromNetwork(request, timeout) {
return new Promise(function (fulfill, reject) {
var timeoutId = setTimeout(reject, timeout);
fetch(request).then(function (response) {
}, reject);

With this recipe, requests are intercepted by the service worker and passed to the network. If the response takes too long, the process is interrupted and the content is served from a local cache instead.

Time limited network or cache can actually be combined with any other technique. The strategy simply gives the network a chance to answer quickly with fresh content.

User feedback

We want to know if recipes are useful, and if you find them clear or confusing. Do they provide unique value or are they redundant? We’ve added Disqus comments to recipes so you can share your feedback. Log in with Facebook, Twitter, Google or Disqus, and tell us how this recipe has served you or participate in the discussion about recommended use cases.

And more to come

We won’t stop here. More recipes are coming and new enhancements are on their way: a improved way to ask for recipes, an easier contribution pipeline, a visual refresh and a renewed recipe layout are things on our radar. If you like please share them with your friends and colleagues. Feel free to use these recipes in your talks or presentations, and, most importantly, help us by providing feedback in the form of on site comments, filing GitHub issues or by tweeting me directly 😉

Your opinion is really appreciated!

About Salva

Front-end developer at Mozilla. Open-web advocate, I love programming languages, cinema, music, video-games and beer.

More articles by Salva…

A Quantum Leap for the Web

A Quantum Leap for the Web

Oct 27
Over the past year, our top priority for Firefox was the Electrolysis project to deliver a multi-process browsing experience to users. Running Firefox in multiple processes greatly improves security and performance. This is the largest change we’ve ever made to Firefox, and we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months.

But, that doesn’t mean we’re all out of ideas in terms of how to improve performance and security. In fact, Electrolysis has just set us up to do something we think will be really big.

We’re calling it Project Quantum.

Quantum is our effort to develop Mozilla’s next-generation web engine and start delivering major improvements to users by the end of 2017. If you’re unfamiliar with the concept of a web engine, it’s the core of the browser that runs all the content you receive as you browse the web. Quantum is all about making extensive use of parallelism and fully exploiting modern hardware. Quantum has a number of components, including several adopted from the Servo project.

The resulting engine will power a fast and smooth user experience on both mobile and desktop operating systems — creating a “quantum leap” in performance. What does that mean? We are striving for performance gains from Quantum that will be so noticeable that your entire web experience will feel different. Pages will load faster, and scrolling will be silky smooth. Animations and interactive apps will respond instantly, and be able to handle more intensive content while holding consistent frame rates. And the content most important to you will automatically get the highest priority, focusing processing power where you need it the most.

So how will we achieve all this?

Web browsers first appeared in the era of desktop PCs. Those early computers only had single-core CPUs that could only process commands in a single stream, so they truly could only do one thing at a time. Even today, in most browsers an individual web page runs primarily on a single thread on a single core.

But nowadays we browse the web on phones, tablets, and laptops that have much more sophisticated processors, often with two, four or even more cores. Additionally, it’s now commonplace for devices to incorporate one or more high-performance GPUs that can accelerate rendering and other kinds of computations.

One other big thing that has changed over the past fifteen years is that the web has evolved from a collection of hyperlinked static documents to a constellation of rich, interactive apps. Developers want to build, and consumers expect, experiences with zero latency, rich animations, and real-time interactivity. To make this possible we need a web platform that allows developers to tap into the full power of the underlying device, without having to agonize about the complexities that come with parallelism and specialized hardware.

And so, Project Quantum is about developing a next-generation engine that will meet the demands of tomorrow’s web by taking full advantage of all the processing power in your modern devices. Quantum starts from Gecko, and replaces major engine components that will benefit most from parallelization, or from offloading to the GPU. One key part of our strategy is to incorporate groundbreaking components of Servo, an independent, community-based web engine sponsored by Mozilla. Initially, Quantum will share a couple of components with Servo, but as the projects evolve we will experiment with adopting even more.

A number of the Quantum components are written in Rust. If you’re not familiar with Rust, it’s a systems programming language that runs blazing fast, while simplifying development of parallel programs by guaranteeing thread and memory safety. In most cases, Rust code won’t even compile unless it is safe.

We’re taking on a lot of separate but related initiatives as part of Quantum, and we’re revisiting many old assumptions and implementations. The high-level approach is to rethink many fundamental aspects of how a browser engine works. We’ll be re-engineering foundational building blocks, like how we apply CSS styles, how we execute DOM operations, and how we render graphics to your screen.

Quantum is an ambitious project, but users won’t have to wait long to start seeing improvements roll out. We’re going to ship major improvements next year, and we’ll iterate from there. A first version of our new engine will ship on Android, Windows, Mac, and Linux. Someday we hope to offer this new engine for iOS, too.

We’re confident Quantum will deliver significantly improved performance. If you’re a developer and you’d like to get involved, you can learn more about Quantum on the the Mozilla wiki, and explore ways that you can contribute. We hope you’ll take the Quantum leap with us.

Self Hosted vs. Free [Infograph]

Self Hosted vs. Free [Infograph]

Editorial StaffSeptember 30th, 2016
When starting out as a beginner, this question comes in everyone’s mind. Which one is better? Is it better to pick the Self Hosted, or is it better to go with Free In this article, we provide you with an infographic that compares vs side by side with list of pros and cons. We also tell you in the end which one is our pick. Click on the image to see the full version of the Infographic.


Self Hosted vs. Free [Infograph]

Editorial StaffSeptember 30th, 2016
When starting out as a beginner, this question comes in everyone’s mind. Which one is better? Is it better to pick the Self Hosted, or is it better to go with Free In this article, we provide you with an infographic that compares vs side by side with list of pros and cons. We also tell you in the end which one is our pick. Click on the image to see the full version of the Infographic.

Difference between self-hosted vs Free blog

Note: We have updated this infographic because there was a huge debate about the comparison. The goal of this infographic is to compare Self Hosted vs. FREE*. We were called out by many folks saying, offers CSS upgrades etc. etc. But apparently, we were not clear enough…

View original post 933 more words

Self Hosted vs. Free [Infograph]

Self Hosted vs. Free [Infograph]

Editorial StaffSeptember 30th, 2016
When starting out as a beginner, this question comes in everyone’s mind. Which one is better? Is it better to pick the Self Hosted, or is it better to go with Free In this article, we provide you with an infographic that compares vs side by side with list of pros and cons. We also tell you in the end which one is our pick. Click on the image to see the full version of the Infographic.

Difference between self-hosted vs Free blog

Note: We have updated this infographic because there was a huge debate about the comparison. The goal of this infographic is to compare Self Hosted vs. FREE*. We were called out by many folks saying, offers CSS upgrades etc. etc. But apparently, we were not clear enough in the title when we said we were comparing to only FREE This new infographic indicates with a * all the upgrades that are possible. Another reason for the update was that the numbers used in the infographic were outdated. vs (Infographic)

Self Hosted vs Free

Convinced that you should use now? Want to switch away from Here is a tutorial on how to properly move your blog from to vs (Comparison)

If you don’t want to read the infographic, then here it is in the text: Benefits

It’s free and super easy to use.
You own your data. You are in full control. Your site will NOT be turned off because someone decides that it is against their terms of service (as long as you are not doing something illegal). You are in control.
You can upload and use plugins.
You can upload custom themes. Modify theme files (not just styles) if needed.
You can make money from it by using your own ads, and doing things your way.
Custom Analytics and Tracking Cons

Like any other website, you need a good web hosting. This bits cost you money somewhere from around $3 – $7 per month (as your site grows, your hosting costs will too). But then you would be making enough money to cover the costs 🙂
You are responsible for updates. WordPress upgrades require 1 click (Not too hard eh).
You are responsible for backups, but thankfully tons of amazing plugins are out there like BackupBuddy.
You are responsible to prevent SPAM, but if you enable Akismet (which comes built-in with, then you won’t have to worry about it. Benefits

It’s free for upto 3GB of space. After that you will have to pay for space ($19.95 per year for 5GB) or ($289.97 per year for 100GB).
They make regular backups of your site. Cons

They place ads on all free websites. Did you really think it was free without a catch? If you don’t want your users to see ads, then you can pay them $29.97 per year to keep your site ad-free.
You are NOT allowed to sell ads on your site unless you receive 25,000 pageviews per month. In which case, you have to apply to try their feature called Ad control. The approval process doesn’t cost you any money, but you have to split your revenues 50/50 with them *Ouch*
You cannot use plugins. Yup WordPress is well known for it’s flexibility due to the plugins. does not allow you to use plugins! If you want to use plugins, then you have to move to their VIP program which starts at $3750 per month. No joke.
You cannot use custom themes. Yup, you have to be stuck with their choice of themes which is being used on hundreds of millions of sites. They do offer a “design upgrade” which should really be called CSS upgrade for $30 per year. Meaning, you can change the color of your site. But if you want to add something really custom, you cannot.
You are restricted to their analytics. You cannot use custom analytics software because you cannot add custom codes.
They can delete your site at anytime if they think it violates their Terms of Service.
They will change your theme without your permission if the founder doesn’t like the theme developer (yup it happened).
Even if you pay for their upgrades, you still have to tell others that your site is powered on vs (Which one is Better for You?)

If you are a personal blogger who do not care about making money from their sites, then go with If you are a blogger trying to make blogging into a career, then you want to use self hosted Often people will say, self-hosted WordPress will cost you money. For a small enough site, it is actually cheaper.

Let’s say you use, buy their custom domain ($17 per year), pay for ad-free option ($29.97 per year), and get custom design upgrade ($30 per year). That total is $76.97, and you are still not in full control.

For, you can use Bluehost (officially recommended by WordPress) which costs $3.95 per month so $47.4 per year, and it includes a free domain name. If you go with other web hosting companies, then you will pay a similar price, but you won’t get a domain. However, you can get a domain name for $10 from Godaddy or NameCheap. Your total would come to $57.4 per year. You will have full control over everything.

Here’s a step by step guide on how to start a WordPress blog.

Is one easier to use than the other? Nope. The interface of both are very similar. We have free WordPress video tutorials that will guide you through the whole dashboard.

We always recommend everyone to use, so you are in full control of your site. The final choice is always yours 🙂

P.S. Here is a tutorial on how to properly move your blog from to

We hoped you like the infograph. If you liked it, make sure you share it on Twitter, Facebook, or any other site that you like (ofcourse with a credits link back to WPBeginner – preferably this article).

Also don’t forget to subscribe to our YouTube Channel for tons of free WordPress video tutorials.

Editorial Staff at WPBeginner is a team of WordPress experts led by Syed Balkhi. Page maintained by Syed Balkhi.