(Dec 3) An update for ghostscript is now available for Red Hat Enterprise Linux 7. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability
WordPress 5.0 is almost ready for release, including an all-new content editing experience. Volunteers all across the project are gearing up for the launch and making sure everything is ready. Read on to find out what’s been happening and how you can get involved.
The release date for WordPress 5.0 has not yet been set, but the second release candidate (RC) is now available. The final release date will be determined based on feedback and testing of this RC. The Core development team has been posting daily updates on the progress of their work on v5.0, with the number of open issues for this release decreasing every day.
The primary feature of this release is the new editor that will become the default WordPress experience going forward. A number of people have been seeking more direct feedback from the release leads about the progress of this release, which @matt has facilitated by hosting one-to-one discussions with anyone in the community who wanted to talk with him about it. He has also published an extended FAQ covering many of the questions people have been asking.
Alongside the development of the new editor, the Mobile team has been working hard to bring the WordPress mobile apps up to speed. They plan to make a beta version available in February 2019.
Want to get involved in developing WordPress Core in 5.0 and beyond? Follow the Core team blog and join the #core channel in the Making WordPress Slack group.
WordPress user documentation has long been hosted on the WordPress Codex, but for the past couple of years an ambitious project has been underway to move that content to a freshly-built WordPress-based platform. This project, named “HelpHub,” is now live and the official home of WordPress Support.
There is still plenty of content that needs to be migrated from the Codex to HelpHub, but the initial move is done and the platform is ready to have all WordPress’ user documentation moved across. HelpHub will be the first place for support, encouraging users to find solutions for themselves before posting in the forums.
Want to get involved in populating HelpHub with content, or with its future development? Follow the Documentation team blog and join the #docs channel in the Making WordPress Slack group.
The WordPress community in Spain has been hard at work making sure as much of the WordPress project as possible is available in Spanish. They have recently translated more of the project than ever — including WordPress Core, WordPress.org, the mobile apps and the top 120 plugins in the Directory.
This achievement has largely been possible due to the fact that the Spanish translation team has over 2,500 individuals contributing to it, making it the largest translation team across the whole project.
Want to get involved in translating WordPress into your local language? You can jump straight into translations, follow the Polyglots team blog and join the #polyglots channel in the Making WordPress Slack group.
If you have a story we should consider including in the next “Month in WordPress” post, please submit it here.
It’s common to be managing many different WordPress instances at once. Whether it’s for different businesses or multiple websites for the same business. That’s why, WordPress made managing lots of different sites easier via its multi-site functionality. However, which use cases are a good fit for WordPress Multisite? And when should you use a unique WordPress instance instead?
WP Multisite can save you time and frustration but comes with several restricting factors. Let’s take a closer look at what WordPress Multisite is, and which scenarios benefit from it most.
WP introduced Multisite from version 3.0 of WordPress onwards. With WP Multisite, you can run a number of virtual sites using a single WordPress instance. To external users, these sites look like discreet websites. But in fact, they run using the same code and the same database.
Each virtual site in a WP Multisite setup can have its own domain too. But the sites are all administered from a single WordPress instance.
Multisite will hold plenty of advantages for many admins. Because you can save time, money and stress. All by using a single WP instance to service several different websites by means of the WordPress Multisite feature. Here are the advantages.
With WordPress multiple installations, each WP instance consumes a lot of resources just to stay alive. You need enough disk space and RAM to run WordPress. And this increases with the more instances you put on a server. Multisite from WP reduces this load because it uses one instance and one code base.
The same goes for the plugins and themes you use on WordPress. Because with Multisite, you can use a single plugin and theme instance. So you don’t need to keep several copies of the same code on your machine just to run discreet websites. You can effectively run them using the same code.
It’s quicker and easier to manage updates for plugins, themes and the entire WP CMS with just one code base. You only need to update and bug-fix once. Then, you can stick to a single backup for both WP and the SQL database. Optimizing WordPress is also a pain – but with WordPress Multisite’s single codebase, you only need to optimize once.
It also helps to have just one set of credentials when you administrate WP. You can manage all content from one console. Of course, you also save time because you don’t need to set up WordPress for every new website.
Users see the websites in WP Multisite as discrete websites, and individual sites can use their own domains. And this is true for SEO too! Search crawlers simply see each domain as a separate site. So, using WordPress Multisite won’t affect your SEO results.
You can’t really use WP Multisite for discrete businesses. This is because of too much sharing in the visual styling process, thanks to shared themes and shared admin access. Here are the scenarios where WordPress Multisite won’t work that well.
Every user with access to a specific site in WordPress Multisite has access to all sites in WP Multisite. You can’t wall sites off from a user permission perspective. This goes for site plugins too. Themes and plugins have reach across all the sites in a WordPress Multisite instance. So a rogue plugin can break all your sites.
Furthermore, shared plugins and themes can be a problem. Because making a change to a plugin or theme will affect all sites simultaneously. This means that the sites in a WordPress Multisite setup should really overlap.
Every site in the WP Multisite installation uses the same database. So, you may find that multiple page requests lead to performance problems. You can manage this, but without WordPress Multisite, it wouldn’t be an issue to begin with.
Does the same business or support staff run the sites? Are these sites similar enough to share themes and plugins? If you work for a business that needs multiple similar sites, such as an event manager, WordPress Multisite is a good choice. But choose WordPress multiple installations when different businesses own the sites, and where sites use vastly different functional layers. We also suggest to read this article on how to manage WordPress multiple sites. You’ll find a review of solutions for both approaches.
The post How to choose between WordPress Multisite and multiple WordPress instances appeared first on Plesk.
One thing producing innovative movements in companies is DevOps. Let’s now clarify the phases of the iterative DevOps cycle: Planning, Development, Continuous integration, Deployment, Operation and Monitoring.
It’s important to understand that it’s one of multiple representations, not the definitive canon, simplified into 6 main phases. However, it’s not a cascade cycle where the phases are separated by boundaries. Nor are initiated when the previous one has ended completely. Now, let’s look at each DevOps cycle phase in more detail.
Every project needs a vision that indicates the ultimate work goal to its participants. Defining a set of functionalities giving each iteration value, the criteria to be fulfilled and the end – for each project phase. A Living Product Stack which continuously supports a process of gardening – from a business point of view.
This feeds the different phases of development and operations. Also addressing changes and evolutions according to a continuous improvement process, based on continuous feedback. It’s also important that Business and Management get training on tools and metrics in order to have enough visibility of the project’s development.
This phase is where the project gets built. Writing code, designing infrastructure, automating processes, defining tests or implementing security. It’s where, at present, you’ll find the most important effort in automating repetitive or complex actions.
However, the most important part of this phase is evidence. Either in a management application, operations with data or in the deployment of virtual infrastructure. Developers will store code in a code manager that allows historical viewing, branches, versioning, and more. But this isn’t enough, and each piece built must include its own automated tests.
Meaning, the mechanisms with which the system itself can ensure that what we have done is correct. That it doesn’t fail or negatively impact other parties, meets the acceptance criteria, and points out developmental errors.
Continuous integration is to automate the mechanism of review, validation, testing and alerts of the value built in the iterations, from a global point of view. The arrival of DevOps and the concepts of Infrastructure as a code, make IT also a full participant of this phase.
This is the unique functionality or feature, built in the development environment, together with the automatic tests that ensure it works well. Then published in a service that integrates it with the rest of the application.
Tests include ones for each functionality, integration tests of the whole application, functional tests, acceptance tests, quality analysis of the code, and regression tests. And if something fails, the early warning will pop up, indicating which piece/ line is breaking the system.
Ultimately, the closer you get to the moment of initiating the critical path of deployment, the quieter you get. Because more evidence is included in the work. Stay tuned for part 2 of the DevOps Cycle tomorrow, where we’ll discuss the final three phases: automated deployment, operations and monitoring.
The post The DevOps Cycle 1: Management, Planning and Continuous Integration appeared first on Plesk.
(Nov 27) Several security issues were fixed in WebKitGTK+.
50 queries. 8.75 mb Memory usage. 0.351 seconds.