<div class="rss-widget"><ul><li><a class='rsswidget' href='http://ma.tt/2015/11/cool-uses-of-wp-api/' title='What’s the coolest uses and applications built on top of WordPress APIs that you’ve seen? I’m looking for some examples to highlight in the State of the Word next month.'>Matt: Cool Uses of WP-API</a></li><li><a class='rsswidget' href='http://wptavern.com/how-to-replace-wordpress-default-avatars-with-wapuu' title='Out of the box, WordPress allows you to configure the default avatar that displays for commenters that don’t have one. The choices leave a lot to be desired. Thanks to a new plugin created by Lee Willis, called Wapuuvatar, you can replace default avatars with images of Wapuu. Settings for Wapuuavatar If you’re not familiar with Wapuu, it’s the official, GPL Licensed mascot of the WordPress project. Throughout the year, a number of WordCamps and local communities across the world have created local versions of the character. In fact, the Tavern has its own Wapuu. WP Tavern Wapuu The plugin has two settings. You can either replace the default avatar with random Wapuus or replace all Gravatars with Wapuu. Wapuuavatar uses a library of images from the official Wapuu GitHub repository and art work created by Michelle Schulp. Here’s how it looks in action on WP Tavern. Wapuuavatar on the Tavern Wapuuavatar is an easy way to replace boring avatars with works of art. The plugin works without issue on WordPress 4.4 beta 4 and is available for free on WordPress.org. '>WPTavern: How to Replace WordPress’ Default Avatars With Wapuu</a></li><li><a class='rsswidget' href='http://wptavern.com/why-some-theme-authors-are-waiting-two-months-or-more-for-their-first-review' title='photo credit: Βethan – cc Within the last few weeks, we’ve received emails from readers wanting to know why it’s taking so long for new themes to be reviewed on WordPress.org. Some theme authors are having to wait two months or more for their first review. Ashley Evans submitted her theme in June and she’s yet to complete the review process. Throughout that time period, both Evans and the reviewer experienced delays in responding to each other. A few months into the review, the reviewer disappeared and Evans was assigned a new reviewer two days ago. Understandably, the experience has discouraged Evan’s from submitting anymore themes to the directory: Back in August, I said, ‘Screw it’ and released the theme as a free download on my blog. This process has basically made me vow to stick to adding plugins to the repo and stop adding any more themes. I’m not blaming the theme review team since I can only imagine how much stuff they have to wade through. It’s just sad that the process has discouraged me from ever doing it again. On October 9th, Tammie Lister updated the Theme Review queues and identified a number of themes that fell through the cracks. Most of those themes were approved or are still in the review process. The System is Broken Members of the WordPress Theme Review team agree that the system is broken. In June, the team published its suggested roadmap to improve multiple facets of the review process. One of the items on the list to help cut down the review queue is the auto-approval of theme updates. However, the team is still hard at work trying to code and implement changes to improve the system. Help Them Help You photo credit: Rob Shenk via – cc One of the items high on the team’s to-do list is to put more effort towards education. In order to do that, Justin Tadlock says the team has to free up resources, “We need to free up our biggest resources, which are the team members themselves. However, we can’t free up those people when they’re spending 100% of their time doing reviews.” The most important thing theme authors can do to speed up the review process is to check that your theme meets the Theme Review Requirements. According to Tadlock, “The majority of themes submitted don’t follow the guidelines which considerably slows down the process. Themes will often have 20-30 issues or more. If we can get to a point to where the majority of submissions only have a few minor issues, we really wouldn’t have a queue.” Theme authors who test their themes against Theme Unit Test Data and the Theme Check Plugin substantially improve the system for everyone. What the team needs most is help. Tadlock offers three ways contributors can get involved to improve the situation.  Doing reviews. Tackling Meta Trac tickets related to the theme directory. Writing tutorials.  Tadlock isn’t sure how to get theme authors to raise the quality of their themes before the initial review, “That’s the sort of feedback I want to see from fellow theme authors. What do we need to do to help them get their themes ready before submission?” How to Get Involved The team is always in need of more theme reviewers. Reviewing themes is a great way to learn theme development and what not to do. If you’re interested in reviewing themes, read the following document from the Theme Review Handbook. It explains how to set up a testing environment with an example of a testing workflow. The Theme Review Team also has a project meeting every Tuesday, November 10, 2015, 1:00 PM EST in the #themereview channel on Slack. Exercise Patience Exercising patience is a difficult thing to do if you’ve already waited eight weeks or more for the first review. However, fixing the system is going to take time. If you want to know about the status of your theme and it has an assigned reviewer, you should ask for a status update within the ticket. If your theme doesn’t have an assigned reviewer, you can ask about its status in the Theme Review Team Slack channel with a link to the theme. '>WPTavern: Why Some Theme Authors Are Waiting Two Months or More for Their First Review</a></li><li><a class='rsswidget' href='http://wptavern.com/impervas-web-application-attack-report-shows-spam-is-wordpress-largest-security-threat' title='Imperva, an international cyber security company founded in 2002, published its 2015 web application attack report. The report includes a thorough analysis of attack data obtained through its WAF or Web Application Firewall. In the report, Imperva’s application defense center group analyzed 297,954 attacks and 22,850,023 alerts on 198 of the applications it protects behind its WAF. The data is from January 1st, 2015 – June 30th, 2015 and provides a solid overview of the number and types of attacks web applications are experiencing. The report covers a lot of ground but for the purpose of this site, I’m focusing on WordPress. Analysis Methodology Automated tools recorded the web applications’ traffic and malicious events were documented in log files. Imperva’s application defense center group analyzed the data using special-purpose software and its knowledge base. You can find more information that explains how the data was analyzed on page seven of the report. WordPress Is the Most Attacked CMS Application Out of the 198 applications protected, Imperva identified 55 that are CMS-based, 20 WordPress applications, 11 Drupal, and 24 that are based on 11 other CMS frameworks. Average Number of Incidents per Applications CMS Slice According to the report, CMS applications suffered an average of three times more attacks than non-CMS applications. WordPress applications suffered from 3,497 attacks in the reported period which is 250% more than non-CMS Applications. Note from the above image that spam attacks against WordPress outnumber all other types of attacks. Imperva says the attraction to CMS applications, especially WordPress is not new. CMS frameworks have an open nature,  with open developer communities that generate a never-ending sequence of plug-ins and add-ons, with varying levels of security. This situation has led to corresponding never-ending flow of CMS vulnerabilities, with WordPress as the leading CMS taking the lead also in the amount of published attacks. Furthermore, the fact that WordPress and other CMS applications resemble each other facilitates automated scanning attacks that work effectively on all applications of this type with only minimal adjustments. Varying levels of security in plugins have led to many vulnerabilities making WordPress the leader in the amount of published attacks. Proportions of Attacks Taking spam attacks out of the equation, the most popular attack type against WordPress applications is (RCE) Remote Command Execution with (RFI) Remote File Inclusion taking second place. Proportion of Attack Types  Remote File Inclusion (RFI) is an attack that allows an attacker to include a remote file, usually through a script, on the web server. This attack can lead to data theft or manipulation, malicious code execution on the web server, or malicious code execution on the application client side such as JavaScript execution, which can lead to other attacks. This vulnerability occurs due to the use of user-supplied input without proper validation.   Remote Command Execution (RCE) is an attack that allows the attacker to execute operating system commands in a system shell. The attack exploits applications that suffer from insufficient input validation in conjunction with passing this input to a system shell. The attacker’s payload is executed with the same privileges of the vulnerable application and can lead to full compromise of the server.  Even though the other monitored CMS applications are written in PHP, RFI attacks on WordPress are significantly higher than all other applications. Imperva offers one possible explanation: Attackers don’t target a specific application, but start with scanning the Internet for vulnerable applications. A Low Hanging Fruit approach that is simple and effective for the detection of potential RFI targets, would be to run a WordPress test and mount an RFI attack in case of success. The report goes on to show geographic attack trends, PHP vs non-PHP attack incidents, traffic volume, case studies, and more. No Need to Panic Even though it’s only six months of data, the results don’t surprise me. WordPress is used on a quarter of the top 10 million websites ranked by Alexa so of course its going to be the most attacked CMS. The data in the report reinforces my belief that every public site online is likely being scanned or attacked multiple times a day. Unless you’re using a service or plugin that logs these types of attacks, its hard to know how popular of a target a site is. If you’re aware of a plugin or service that provides a user-friendly interface that shows and explains the attacks it’s protecting against a site, please send me a link in the comments. Basic Security Principles It’s imperative that you use a strong password and two-factor authentication. Consider using a service like Clef that allows you to login to WordPress without a password. I also highly encourage you to read the WordPress security whitepaper to learn how WordPress protects itself against common attacks mentioned in Imperva’s report and how to responsibly disclose a WordPress security vulnerability. '>WPTavern: Imperva’s Web Application Attack Report Shows Spam Is WordPress’ Largest Security Threat</a></li><li><a class='rsswidget' href='http://wptavern.com/wordpress-freelancer-adam-soucie-on-the-dangers-of-accepting-credit-cards' title='If you’re running or opening a new WordPress business, you should read Adam Soucie’s warning on the dangers of accepting credit cards. Soucie, a WordPress Developer based in Orlando, Florida describes what happened after working with a client that claimed to be hearing disabled. Soucie went through the usual process of sending over a contract, bringing in a designer, discussing scope, and sending over an invoice. The client then claimed to be in the hospital and requested help to pay for one of the contractors involved in the project because he didn’t accept credit cards. According to Soucie, this should have been the red flag: But I ignored it because I’ve also been a trusting person who is sympathetic to people with disabilities.  Plus I figured I had proof of everything, so I’d be protected.  I was so wrong. To make a long story short, the ‘client’ was paying with stolen credit cards and the other contractor was in on the scam.  I discovered the scam when they started getting pushy about the contractor receiving his payments.  When leaving to make the final payment, I got a call from the person whose credit card info was stolen.  I reached out to my ‘client’ and she had disappeared. As the merchant, Soucie was liable for the transaction. After not receiving help from the FBI Cyber Crimes division and the credit card companies, QuickBooks, Soucie’s payment processor, went after him for the total amount of $10,000. He was able to get the amount slightly reduced after working with QuickBooks. What looked like an awesome project quickly turned into a nightmare. I highly encourage you to read his article as it includes tips to protect yourself and why you shouldn’t be too trusting. What advice do you have for freelancers who accept credit card payments? What signs should freelancers look for to avoid fraudulent scams like this one? '>WPTavern: WordPress Freelancer Adam Soucie on the Dangers of Accepting Credit Cards</a></li></ul></div>