There's a new Joomla version out - one reason to upgrade is the old version has a cross-site scripting vulnerability.
- Version affected 2.5.14 and earlier 2.5.x versions. 3.1.5 and earlier 3.x versions.
- Vulnerability: Inadequate filtering leads to XSS vulnerability in com_contact.
The other reason to upgrade is that Joomla 3.2 has a host of exciting new features. Here's one of those trendy infographics to give you the details
Joomla 3.2 - 10 new features - An infographic by the team at JoomlArt.com
We make every effort to keep our hosting and network as fast as possible. We have multiple redundant links out to the rest of the internet and our network is entirely under our own control.
We recommend customers use third-party sites to test their websites as results from your own browser can be misleading (due to caching).
Website loading speed is mainly affected by the page design itself - one with a lot of large images is clearly going to take longer than a text only page.
However a customer recently responded to our annual survey and I happened to check his site against third-party testing site Pingdom.com. Have a look at these cool results:
Yes your eyes do not deceive you, MSO.ORG.UK is faster than 96% of all tested websites
Logging to file could also be useful when debugging very visual things (where you don't want extra messages) such as themes. Also background scheduled cron jobs are the same as Ajax calls and run with no user interface so you need to send the messages to file not to the screen.
Although it is possible to configure the logging modes yourself via php.ini or .htaccess, WordPress sets up some constants in the WP_CONFIG.php file which make it simpler to setup debug logging to file.
The setting first is the master control for debugging.
Without this setting nothing will get logged.
The next setting is
This tells WordPress to log everything to the /wp-content/debug.log file, if you want to log to an alternative location do not include this setting and use the settings described in the first reference below.Finally we need to turn off the display of setting to the user (or Ajax call) using the following setting
if you set these three settings then you should have logging to file. It's worth turning this off once your debugging session has finished as the file can get quite large quite quickly.
The Apache Tomcat Project is proud to announce the next release candidate for Apache Tomcat 8 - 8.0.0-RC3 (alpha). Tomcat 8 is aligned with Java EE 7. In addition to supporting updated versions of the Java EE specifications, Tomcat 8 includes a number of improvements compared to Tomcat 7. The notable changes include:
- Support for Java Servlet 3.1, JavaServer Pages 2.3, Java Unified Expression Language 3.0 and Java WebSocket 1.0.
- The default connector implementation is now the Java non-blocking implementation (NIO) for both HTTP and AJP.
- A new resources implementation that replaces Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories with a single, consistent approach for configuring additional web application resources. The new resources implementation can also be used to implement overlays (using a master WAR as the basis for multiple web applications that each have their own customizations).
Apache Tomcat 8.0.0-RC3 includes numerous fixes for issues identified in RC1 as well as a number of other enhancements and changes. The notable changes since RC1 include:
- Switch to UFT-8 by default for connectors and example web applications.
- Switch to the asynchronous logger and one line formatter by default.
- Add Servlet 3.1 non-blocking IO support to the AJP connectors.
Full details of these changes, and all the other changes, are available in the Tomcat 8 changelog.
The purpose of this release candidate is to give users an opportunity to test Tomcat 8 and provide feedback to the Tomcat community. It has been given an alpha status which means that it is not judged as being ready for production usage. The implementations of the 4 Java EE 7 specifications are all complete but there is some internal refactoring to be completed before the alpha label is removed.
The WordPress brute-force login attacks show little sign of abating and we recommend all users ensure their sites are secured against this attack.
Since spring 2013, hackers have been calling the WordPress login url with "standard" usernames (like 'admin') and thousands of passwords. In our experience nearly all users have 'admin' as a user account so this makes them especially vulnerable.
Well - not a solution exactly but it should protect your site being hacked.
The solution we propose is to change your username to something only you know about. If you are creating a new WordPress site, don't use the default 'admin'. Choose a new username.
If you have an existing site, you can't simply delete the user 'admin' - therefore there are lot's of free plugins around to change it instead. The one we've been using is called 'Username Changer'. Install it, activate it, change your username and then remove it. It's a one off job.
2020Media can help
Additionally 2020Media would like to see these WordPress attacks stop - realistically this is not going to happen - it's a distributed attack from botnets, and things will change only when it's not worth the hackers while any more.
2020Media are happy to change your login username for you plus we can add additional server-side security which will mitigate the denial-of-service aspects of the attack.
The Managed WordPress service from 2020Media is something anyone not logging in to their WordPress site on a weekly basis should seriously consider. Even if you do, get peace of mind as updates to WordPress, Themes and plugins are done for you. Read more