The short version:
Make sure your Firefox and Edge browsers are on the latest release.
Sites can gather sensitive data if a prior site served up video or audio files.
Keeping the WordPress login intact between Cypress.IO tests was a challenge. There are plenty of Cypress.IO articles about login management and just as many about “anti-pattern” which lean toward the “login/authenticate between each test”. I don’t really want to test the WordPress login that often. I’m pretty damn sure it works. What I want to do is run my tests efficiently.
Unfortunately the “out of the box” examples, which I’ve been following, forgets about your login state between each test. Take my original Cypress.IO test — it logs in, configured the WordPress permalinks, logs out, does the Cypress.IO WordPress login again, sets the theme.
An interesting article I found in my Google News feed today from Venture Beat:
“WordPress now powers 30% of websites”
WordPress now powers 30 percent of the web, according to data from web technology survey firm W3Techs.
It’s worth noting here that this figure relates to the entire Web, regardless of whether a website uses a content management system (CMS) or not. If we’re looking at market share, WordPress actually claims 60.2 percent, up from 58.7 percent in November 2015. By comparison, its nearest CMS rival, Joomla, has seen its usage jump from 2.8 percent to 3.1 percent, while Drupal is up from 2.1 percent to 2.2 percent.
I have multiple sites using Jetpack services at various levels from the Free through the Premium service. Some sites are playing nicely with the Jetpack services at WordPress.com but not all sites. This post is my notes repository for debugging this issue.
I recently found that I needed to Profile WordPress Cron to figure out the best way to improve the processing time on background file imports.
In an effort to better handle on large location imports in Store Locator Plus, I re-architected the Power add on to split the process into 3 steps. The first step uploads the file to the server; something that is typically fairly fast and only ties up a user’s web browser for a few minutes as most people are no longer on dial-up. The second step, the reason WordPress Cron is now in play, is to fire off a background process via WP Cron to then parse the CSV file. This second process is the one I want to profile.
Luckily I am using a typical VVV setup as part of my development environment. It has Webgrind, a PHP cache grind file reporting tool, already enabled “out of the box”. I only need to run the debug_on command from the Virtualbox command line and then add &XDEBUG_PROFILE to the end of any URL request to get a view into what functions are called and how much CPU time they are eating up.
Things get tricky if you want to profile WordPress Cron processes though. Since they are fired off from WordPress automatically, how do you add a GET variable?