New Wordpress Update April 2017: "noopener noreferrer"

[RomesFall]

Edit: LOL at Wordpress. I am not going to say I told you guys so, but...

It does make you wonder what kind of bone-heads they hire there.

 

[built]

Would switching to another cms like Joomla etc be worth it?

 

[Michael]

Would switching to another cms like Joomla etc be worth it?

Worth what? What are you looking for here to warrant a switch to a new CMS?

 

[turbin3]

Would switching to another cms like Joomla etc be worth it?

I wouldn't even bother with Joomla honestly.

Depends what your needs are. If you don't need a high degree of functionality or dynamic function on your site, and if it's mostly text content with some images, what I'd recommend taking a look at is the static site generator, Hugo. It's fast and light out of the box, has a good set of built in features, and for most typical blogging purposes it will work just fine. It also depends how much you really want to code. With Hugo, it uses sort of a Handlebars JS-style syntax where certain things are wrapped in double curly braces. Once you learn a few of those functions, it's really quick and easy to do things like for loops, for example, to generate a post feed or list of items, or whatever. Hugo still doesn't have a massive level of industry adoption, so it's still somewhat experimental and developing. There are plenty of sites in production with it, but just be aware it's more work than something like Wordpress.

Another worth considering, for something that has much wider industry support and more existing custom options (themes, plugins, etc.) is Jekyll, which is also a static site generator. It's slower than Hugo by quite a bit, but honestly, for small sites with a few dozen posts, maybe a hundred or few hundred posts, this is probably not a big deal. There are a ton more resources for Jekyll too, like LOTS of tutorials on YouTube, whereas for Hugo there are only a small handful.

 

[doublethinker]

Hugo looks incredible but will take a long time before it hits v1.0. Why build on untested waters and who knows where the river flows to. The team is also really small or just one guy? I'm not too certain. But I know for a fact there's no related pages functionality yet and that's a deal breaker for me.

I think I read somewhere that @CCarter used PicoCMS. It's not a static site generator, but a flat file CMS. OctoberCMS would be the closest in feel to Wordpress, but uses twig (a good thing imo).

 

[Darth]

Seems to me that most people would spend a huge number of hours that could have otherwise been spent advancing their business trying to replicate some the features, functions, themes etc of Wordpress, just because of a few undesirable changes that for the most part can be fixed quickly anyway?

 

[turbin3]

Static Site = Flat File

Same thing, just different names. Hugo has a good degree of support, with a decent number of people actively developing it and contributing. The nice thing with Hugo is, the content is stored in Markdown files. Markdown is nice in that it's relatively simple and fairly universal for platforms that support it, so you're not really tied in to anything proprietary. WP has plugins for Markdown as well. The idea here would be, if you start using a more "portable" content format, it would be much easier to experiment with other CMS / static site generators. With a pure Markdown file, you could try Hugo. You could also try Jekyll. There are also a number of other CMS that it will work with as well.

I totally get your point, Darth, and I do agree much of the time. Time spent developing is often to the detriment of ROI-generating marketing efforts. The flip side of this, however, is when you are tied to a CMS that really demands that you maintain frequent updates to minimize security vulnerabilities, which correspondingly adds additional management overhead of ensuring nothing breaks in the process. On top of this, if you have WP, make no mistake, people are attempting to hack your site repeatedly, on an ongoing basis. It's not an if with WP, it is a when. That alone, especially from a business standpoint, is a massive risk.

Imagine living in a neighborhood where you know that it is pretty much guaranteed at least 1 to a few times per week, someone was going to attempt a home invasion on your house... Would you continue shoring up your defenses, hardening your home... Or would you just MOVE and bypass the problem entirely.

 

[ryandiscord]

if you have WP, make no mistake, people are attempting to hack your site repeatedly, on an ongoing basis. It's not an if with WP, it is a when. That alone, especially from a business standpoint, is a massive risk.

Run wordfence and you'll see many hack attempts. It's non-stop. They're relentless. It's really only a matter of time.

 

[Klayne]

Static Site = Flat File

Same thing, just different names. Hugo has a good degree of support, with a decent number of people actively developing it and contributing. The nice thing with Hugo is, the content is stored in Markdown files. Markdown is nice in that it's relatively simple and fairly universal for platforms that support it, so you're not really tied in to anything proprietary. WP has plugins for Markdown as well. The idea here would be, if you start using a more "portable" content format, it would be much easier to experiment with other CMS / static site generators. With a pure Markdown file, you could try Hugo. You could also try Jekyll. There are also a number of other CMS that it will work with as well.

I totally get your point, Darth, and I do agree much of the time. Time spent developing is often to the detriment of ROI-generating marketing efforts. The flip side of this, however, is when you are tied to a CMS that really demands that you maintain frequent updates to minimize security vulnerabilities, which correspondingly adds additional management overhead of ensuring nothing breaks in the process. On top of this, if you have WP, make no mistake, people are attempting to hack your site repeatedly, on an ongoing basis. It's not an if with WP, it is a when. That alone, especially from a business standpoint, is a massive risk.

Imagine living in a neighborhood where you know that it is pretty much guaranteed at least 1 to a few times per week, someone was going to attempt a home invasion on your house... Would you continue shoring up your defenses, hardening your home... Or would you just MOVE and bypass the problem entirely.

Why is wordpress targeted so much ? Is it because it's easy to hack and popular ? Any tips on how to reduce the chance on being hacked, without going too hardcore and spending weeks securing the site ?

 

[Ryuzaki]

Why is wordpress targeted so much ? Is it because it's easy to hack and popular ? Any tips on how to reduce the chance on being hacked, without going too hardcore and spending weeks securing the site ?

Partially because it has a login page that nearly nobody changes or protects. People try to brute-force it with common usernames like root, admin, etc. They match those against common passwords. So the best thing you can do is never use a common password or dictionary word as a password, and always use a unique username. The next best is to password protect that entire URL range (wp-admin and wp-login.php) as well as a 2nd layer.

Other reasons are because people don't maintain their installations. So Wordpress, Theme, and Plugin developers, like the idiots they are, will suddenly push an update out while announcing the exact freaking vulnerability to all of the hackers. Then it's a race... who gets there first, the hacker or the webmaster?

Third is because of footprints, or "dorks", which Wordpress and plugins are full of. All you need is to find a vulnerable plugin that's not being maintained by the developer but free to install, use a dork on Google, and you just scanned a giant list of sites vulnerable to MySQL injections, etc.

The targets are almost endless since it's the biggest CMS out there, and their philosophy is to cater to even the most uninformed user. All that hand-holding means more and more complexity and room to screw up.

 

[Darth]

Keeping Wordpress up to date isn't hard. Logging in several times daily shouldn't be hard given the site is your business and you should be working on it. If it is hard, then use something like managewp.com to keep on top of it. Plus WP pushes security updates these days.

The login page, setup a HTpass and/or hide it completely with WPS Hide Login.

And for plugins, just limit them or don't use them/hack stuff yourself.

It's a 5 minute job to secure Wordpress.

 

[turbin3]

It's a 5 minute job to secure Wordpress.

Um yeah, NO. Not if it's your business and you care about it.

I have an OCD-level of maintaining WP installs. Like always updating WP and all plugins within 1 day (in most cases just hours) of updates released. All the typical best practices taken care of. Religious backup and testing on dev servers before deployment. Everything password protected that should be. Servers LOCKED down solid and IP restricted such that only my IP should be able to access the server. SSH keys salted and peppered, along with guess-the-random SSH port number between 2,000 to 60,000 (and BTW, pinging is disabled...so you have a 1/60,000 chance LOL). A whole lot of other stuff too. In the past 2 years I've had 4 successful hack attempts on 2 of my sites, using different vectors, that just totally bypassed any of those security measures. The problem is, PHP is an irrational programming language. The more you learn about it and the insane edge cases created by the language's ambiguity, the more you will grow to never want anything to do with PHP, ever again. On top of that, WP's integration with MySQL is not as secure as it could be, and is actually a bit flawed.

About the only way I could see someone having a truly significant degree of security with WP would be to write an insanely complex plugin (if a plugin could even accomplish it) to basically obfuscate file/folder/component naming conventions and other common attack vectors, such that your entire install's file structure and HTML code was unrecognizable from a WP install (aka URL rewrite the shit out of your site's entire structure/code). That is too far down the low/no-ROI rabbit hole to even be worth considering.

↑​

All of that insanity has driven me to a world of having migrated a majority of my sites to static sites hosted on minimalist Linux servers that are stripped of all unnecessary programs, locked down like Fort Knox, and that NEVER have PHP installed, because I am never going back down that path again! When you sit there and watch your live traffic logs, and see the thousands or tens of thousands of scripted requests for endless WP plugins and system files being fired relentlessly at your server, and you realize that this is happening practically all day every day, you will understand my pain. Hide 'yo wife. Hide 'yo kids. They hackin 'errbody around here!

 

[Darth]

Are we talking about WP specific issues or server and programming language issues? I assumed it was the former.

 

[doublethinker]

It's a 5 minute job to secure Wordpress.

I disagree. Imagine you have 5 installations of wordpress. It sounds efficient for everyone to run the same set of plugins and configuration. Say, wpcache, newspaper theme, social login plugin, social share plugin and social autopost.

But wait! They all have to be paid for, and on a per site basis. Let's also say that you want to put a quiz function. That means another plugin, but maybe only one of the 5 sites really warrants it and you don't want to pay for more.

Now you have a 4 + 1 setup. Not including image compressors, "easy to use" SEO optimizers, image file SEO optimizer that all require you to access the admin interface and change them one by one.

And each one of those plugins has their own style of code in php. If any one of them decides to just not update anymore or their update breaks another plugin, which you will come to know about because it will break your site- and no plugin developer will really help you for free when it comes to supporting integration across plugins.

And not forgetting too, any one of these plugins (typically between 10 to 15 is usually norm) that have a vulnerability, you are screwed. Any one of these plugins break your site, you are screwed. Any one of these plugins slow down the whole site, you are screwed (trying to find which one). Tried fixing any one of these plugins, and maintaining them everytime there's an update, you are not screwed but horribly detracting from the primary goal, making money.

There was one login plugin that was pretty well put together, and expensive too. But it had a backdoor url that gave you access as long as you had that link. NOPE.

I've spent months and ~500$ in wordpress only to call it quits, because I realized how dangerous it was outsourcing these parts to the keyboards of basement warriors. I now use a flat-file cms that I maintain and I absolutely love it.

@turbin3 yeah flat-file and static site mean the same thing, but they do call their platforms as static site generators and flat-file cmses respectively. Generators are not cmses.

 

[CCarter]

It's a 5 minute job to secure Wordpress.

I'm not sure how you are able to review every line of code a plugin you recently installed within 5 minutes to make sure your WordPress install is secure.

If you aren't looking at your plugin's code how do YOU know that it is secure?

How do you know that the developer even knows how to properly secure a plugin?

90% of vulnerabilities of WordPress comes from the plugins. Let's look at an example: a marketer sees new problem within a certain CMS due to an update. There is a simple solution to editing the functions.php file that people can utilize to fix it. But that marketer knows that most people can barely install WordPress let alone edit a file, so they hire a 3rd world developer and pay them $20 to create a plugin that edits the functions.php file for people and releases it for "free".

However the end goal for the marketer is really to get you on their mailing list - it's a $20 cost after all. So a ton of people get on a mailing list - marketer's job is done. The 3rd world developer delivered a plugin and got his $20 which is a good chunk of money considering where he lives. The developer moves on to another plugin or another project, he's a hit a run operations guy. However you have ZERO ways of knowing whether the way he implemented the code to edit that functions.php file is even secure. You don't know if he did quality tests or vulnerability tests. Basically you just installed a plugin from a guy making $20 per plugin onto your business site, and you didn't check whether that code will be solid against an attack.

The dangerous part is that plugin essentially writes to the functions.php file for your website, creating a huge security problem if it can control your whole website. That plugin might also have write ability to create new folders and files on your server. If you didn't review the code you wouldn't know that - and since most people that use simple plugins for small things like that problem aren't going to look at the code they could be sitting on a time bomb. The time bomb might be secured from not going off since WordPress has it's own internal mechanism (they don't) to monitoring this, but if WordPress does an update and removes a function that the plugin was using that plugin can #1 not work anymore (we see this a lot with plugins that are not supported - developer or marketer moved onto another project), or #2 now allows the time bomb to be exposed to the world.

Some random hacker comes around and reads the latest WordPress changes that they log on what they changed and read the latest vulnerability/patches. But they realized that if any plugin were used function XYZ_VERY_BAD_NOW() it would be vulnerable. So they spend days, weeks, months looking for plugins and realized that one old plugin that is no longer supported by the marketer/developer uses the function XYZ_VERY_BAD_NOW() - BAM! He now finds all the websites that run this plugin, and can have each plugin install his code within hundreds of different directories on your website without you knowing. His code then waits 30 days, and starts sending out spam emails on behalf of your domain, or starts editing your website and redirecting traffic - because again the WordPress plugin has the ability to edit the functions.php file.

WordPress's biggest vulnerability is they let 3rd party users create plugins that can essentially write new files, new data, and control whole websites. There are some hoops to jump through to get into the WordPress Plugin directory - however it's doesn't mean that the WordPress team is taking a hard look at the code. Even so it would be impossible to look for EVERY POTENTIAL combination of vulnerabilities. You really think that $20 web developer knows every potential vulnerability for WordPress as they are whipping up that code in less than an hour? On top of that people install plugins that aren't in the WordPress Directory - ones made for email lists - and I can assure you there is even LESS security scrutiny.

Securing WordPress is NOT a 5 minute job - if you think it is you are completely unaware of how truly vulnerable you are when you allow random developers to create plugins that control your website. Even major plugins have huge vulnerabilities as in the case with MailPoet a few years back: MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

The developers were using an outdated method which resulted in that EVEN IF YOU HAD A SHARED ACCOUNT SETUP WHERE ONE SITE INSTALLED THE MAILPOET PLUGIN THE HACKERS HAS FULL CONTROL OF ALL WEBSITES OF THAT ACCOUNT.

The vulnerability allowed an attacker to inject anything they wanted on the site, which could be used for malware injections, defacement, spam and many more nefarious acts.

[..]

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account

[..]

The Result

They get full control of the site.

Sauce: https://blog.sucuri.net/2014/07/mai...ld-breaking-thousands-of-wordpress-sites.html​

I had MailPoet installed on one of my sites, and it took over 3 other domains and the hacker used those sites to send out massive spam emails on behalf of my domains. It took weeks to clean it up, and I had to literally go into every single folder and look at the modified dates of files to see if they were suppose to be there or not. Do you know how many folders WordPress has? (Besides the plugins that seems to add hundreds of folders within themselves to run).

After cleaning up the Trojans and Viruses, I had to submit reconsideration requests to all the emailing blacklisting services like Spamhaus so I can get off their list and get my domains white-listed.

How would you stop a scenario like MailPoet? How is that a 5 minute job? It was a great plugin that was downloaded by millions of WordPress users (still is) - it was believed to be secure until it was not. The developer didn't know they had a massive time bomb on their hand - they didn't intentionally code it that way. And I guarantee you that these developers are more seasoned than the $20 plugin developer that are used for quick growth hacks.

The hackers did not get in the website with the WordPress login.

The hackers didn't need SSH, SFTP, or FTP to control your website/server.

All the hackers needed was you installing a plugin that has an unknown vulnerability - lying in wait until it was exposed.

In fact all the hackers had to REALLY do was wait for the security team to alert the world about a vulnerability and then code up a solution to exploit it - because most website owners aren't going to update plugins right away, some take days, weeks, months - and some NEVER do.

This scenario is one of the reason why I preach minimum plugins - zero if possible, learn to customize your WordPress yourself, and understand more about the foundation where your business operates off of, and know how to secure your server/website - but even then, if you let a simple badly coded plugin into your operation you are dead and you might not even know it.

The reason I go for Flatfile CMSes is there is no way to update or add files without SFTP/SSH into the site. I don't use generators since they can edit files. The only things I have to keep upto date is the software on my server, and make sure my permissions are 100% on par. The problem will come though when a hired employee doesn't know HTML or SFTP to update portions of a website, blogs being on WordPress make things EASIER for users - not safer for the business. In that employee scenario I would put my WordPress install on a separate server (separate subdomain in most cases) and call it a day. There is no way in hell I would have WordPress controlling my WHOLE domain.

 

[turbin3]

I should retract my previous statement about generator vs. flat file cms, as I was a bit too vague and not entirely accurate. @doublethinker is correct. Both store content in static files, eliminating the need for a database, which is what I was getting at, but they function a bit differently. A static site generator, upon running a command (typically), processes the various content files and data files (typically Markdown, TOML, YAML, JSON, or a few other data types) along with any page templates and then generates the final static HTML from those. It's similar in concept to what WP Super Cache does for Wordpress.

With a flat file CMS, typically the generation step is bypassed. With flat file, you'll also have some language or framework that is handling some of the minimally "dynamic" nature of the site (converting Markdown to HTML for example, URL rewrites, etc.), such as PHP or JS in most flat file CMS' I've seen. The other major difference with a flat file CMS is, there are usually a few additional dependencies, such as PHP, Apache, certain JS frameworks, etc, though it can also give you a bit more functionality than a generator might have.

@Darth , we're not trying to bite your head off, so don't let that discourage you. The thing is, quite a few of us here have experienced the absolute worst Wordpress has to offer, to the point where it simply loses out from a risk vs. reward standpoint.

 

[built]

@turbin3 @CCarter

I'm confused now. I started playing around with Jekyll and Hugo. Is this the step forward or should I just avoid generators and use a flat file cms?

 

[doublethinker]

I don't know about @tubin3, but there was a lot of internalized wordpress fucked me for six months for me.

 

[SmokeTree]

WordPress's biggest vulnerability is they let 3rd party users create plugins

This... The second one releases a plugin framework, they lower their security standards to the least capable developer.

I'm going to weight in here and say I'd recommend something like Jekyll that generates static HTML pages. While, yes, generators do have access to the files themselves, using the generator on the server is not best practice and not how I'd recommend doing it. What normally happens is the generator "lives" locally on the machine of the marketer/developer (or a VPS somewhere). The static HTML files that are generated locally are normally checked into a git repo for both the version control capability and also to ease deployment. For deployment, there are various methods, but it's pretty much as easy as logging onto the server and just pulling the changes from the git repo (this is normally automated, lots of options out there). This makes deployment lightning fast as only the changes are being pulled across. The general rule of modern deployment is, if you have to use a SFTP program, you're doing it wrong.

 

[Pushup]

IP restricted such that only my IP should be able to access the server

I know this is easy in .htaccess if you've got a static IP

order deny,allow
deny from all
allow from <your ip>

My ISP changes my IP often enough that I had to abandon this.
But you got me thinking that this is doable with a little tweaking for people with changing IPs:

1. Ping your computer's IP every hour. If it changes, write the IP to your .htaccess that syncs to your various servers (using a sync-capable FTP client like Transmit). Would be good for travelling.
2. Geofence your login to a state. I don't know what my home IP is going to be, but I know it's going to be in California. So limit logins only to that state by installing Apache's mod_geoip and enabling it in /etc/apache2/apache2.conf (Apache 2.4). Example of geofencing .htaccess for wp-admin folder:

<Limit GET POST>
GeoIPEnable On
SetEnvIf GEOIP_REGION CA AllowState
order deny,allow
deny from all
allow from env=AllowState
</Limit>

GEOIP_CITY will be even better, but check if the maxmind db is able to geolocate your city with precision.
The examples I see online all use GEOIP_COUNTRY_CODE to only allow logins from one country.

You can also use the same geofence tactic to cover ssh.

 

[turbin3]

I'm going to weight in here and say I'd recommend something like Jekyll that generates static HTML pages. While, yes, generators do have access to the files themselves, using the generator on the server is not best practice and not how I'd recommend doing it. What normally happens is the generator "lives" locally on the machine of the marketer/developer (or a VPS somewhere). The static HTML files that are generated locally are normally checked into a git repo for both the version control capability and also to ease deployment. For deployment, there are various methods, but it's pretty much as easy as logging onto the server and just pulling the changes from the git repo (this is normally automated, lots of options out there). This makes deployment lightning fast as only the changes are being pulled across. The general rule of modern deployment is, if you have to use a SFTP program, you're doing it wrong.

This is an excellent description of how to think about what a static site generator can do for you. In essence, the build and compilation of all dependencies happens locally. Static files are what gets deployed. This removes most of, if not all of the issue of dependencies from the server as well as code that could potentially be abused. This is why I heavily lean towards the generator direction, as I've reached the point of wanting to cut things down to the bone, removing all possible attack vectors. This may not be what works best or is most efficient for everyone's needs, however. I am thinking about revisiting Pico and/or one or two other flat file CMS' for certain projects, though, as the added functionality is really nice, particularly when you need to delegate work to others and the CMS has a nice GUI.

@built, here's the best summary I can think of, as far as deciding between generator vs flat file cms:

Generator:

• HTML, CSS, and a bit of JS are no big deal for you, and you don't mind the initial coding
• You're comfortable with using the command line, moderately experienced with Git and basic version control (not 100% necessary, but definitely the right way to do it)
  
• You want maximum speed, to eliminate dependencies, and to eliminate pretty much all security vulnerabilities
• Your site is largely a content-based site, blog, magazine, mostly text, some media (avoid for stuff like ecommerce sites or highly dynamic sites, unless you truly know what you're doing)
• You don't mind a total lack of GUI
• You're fine with managing the site and content through your text editor (Sublime, Atom, etc.)
• Easier, quicker server side setup as you're just serving static files

Flat File CMS:

• You want/need a GUI for managing content or other aspects (not all have this, but many do)
• If it has a GUI, this is great for ease of use, especially if you have VA's and team members to delegate to
  
• You need ease of site enhancement through plugins vs. entirely manual code additions
  
• You don't want to have to deal with version control (can still be used, and advisable, but not required)
• You want everything including the GUI / admin interface live on your server, so you're not split between local copies vs. production
• You have multiple users that need GUI access
  
• A bit more involved server side setup, as you'll have a few dependencies (PHP, Apache/Nginx, etc.). Basically like an extremely lightweight and minimalist Wordpress as far as some of them go.

I think the real trick is determining your comfort level with coding and code/file management, as well as the needs of your site. It's basically a time vs. ROI question. Like I mentioned, stuff like ecommerce would be a complex and difficult proposition for a generator, unless you really keep on top of deployments. That being said, as digital marketers, quite often a lot of us are running largely text content-oriented sites that serve some ads as a primary monetization method. In cases like that, the needs are usually pretty simple, and can be served just fine by a generator. The only major issue you might have is, depending on your hosting, you could run into caching issues. For example, hosting a generated static site out of AWS S3 + Cloudfront + R53 (for your custom domain name) + free SSL cert. In a case like that, you may have long cache times, longer than your ads may be live or relevant. In essence, you could run into an issue where you're serving out of date ads and wasting traffic.

Hope that covers it. Anyone chime in if I missed anything obvious.

 

[Rageix]

I know this is easy in .htaccess if you've got a static IP

order deny,allow
deny from all
allow from <your ip>

My ISP changes my IP often enough that I had to abandon this.
But you got me thinking that this is doable with a little tweaking for people with changing IPs:

To get around an IP that changes is to use something like a VPN with a static IP address. Connect to the VPN, connect to your target server.

Furthermore you would rather set up your ip restriction on your server firewall and not in your .htaccess files, but I guess it depends what you're restricting. WP login I guess needs to be done over .htaccess I guess, but ssh wouldn't.

 

[Ryuzaki]

Yeah, if you're only restricting from the .htaccess for wp-admin / wp-login.php then you can still FTP in and change your IP address. This works good for if you travel or decide to go sit at Panera Bread or McDonalds all day.

 

[doublethinker]

particularly when you need to delegate work to others and the CMS has a nice GUI.

I can't believe you did not bold this in red. Do you want to be a solopreneur or entrepreneur! Anyway, What's keeping me from a static site generator is exactly that, scaling internal productivity. And a mature solution that's well documented does not seem to have presented itself to me yet. SaaS like forestry.io are not solutions.

One might consider github/netlify as https://github.com/netlify/netlify-cms seems interesting and would be easy to "pull out". But I am skeptical of it as a system for now.

I would also add that flat file cmses are usually designed for smaller sites (>5000 pages). They can definitely be optimized for infinitely more but you need to plan the way you will want to resolve that and there are plenty of documented ways to do it. This is the primary reason why I'm using flat file cms, documentation and ownership of the solution. I also do not need a GUI CMS, I use an open source private cloud storage like Pydio to publish whatever that's in the cloud storage- because they're all files.

Static site generators are pretty much already set for whatever number of pages your machine can throw out, if you can resolve backend processes

 

[milktea]

Damn, back to the original topic, but this is probably why my Amazon earnings stagnated last month. I saw this noopener thing but didn't think much about. This is the only forum that bothered to mention this issue. Argh... I would have missed it if I hadn't decided to browse @built's posting history.