The Saga Continues
WordPressWordPress was borne of initial idea seeding via B2 (Cafelog) in 2001, which was launched by Michael Valdrighi. In 2003, cofounders Matt Mullenweg and Mike Little forked B2 and created WordPress, an Open Source blogging and now content management system estimated to power the largest number of websites of any individual product (20%). Through the largest thriving community of any website management system, WordPress has grown to include theme designers, plugin developers, webmasters and site developers. With the power of participants, WP now can power anything from small individual blogs to large multi-user social communities to business websites. Core contributing developers include Ryan Boren, Mark Jaquith, Matt Mullenweg, Andrew Ozz, Peter Westwood and Andrew Nacin. WordPress has just recently celebrated its 10 year anniversary.
WPCommunityWPCommunity.com was started as an extension of Web Developer Tom Ford who found WordPress in the early days looking for a solution to power a group of large websites that had outgrown their flat HTML infrastructure. Needing more features, WordPress was chosen based on another user who was kind enough to put together a comparison chart of several platforms, with detailed information. The way this individual was able to present this side by side comparison using WordPress ultimately led to giving it a shot...which led to massive experimentation to the different things it could do. The heavy and growing demand for assistance led to offering such, bringing us to today. Tom Ford has contributed to various other development agencies including TC Websites, WPMU.org and WPML. (as well as solving countless technical issues and working through many full website builds).
WORDPRESS 4.5.1 MAINTENANCE RELEASE After about six million downloads of WordPress 4.5, we are pleased to announce the immediate availability of WordPress 4.5.1, a maintenance release. This release fixes 12 bugs, chief among them a singular class issue that broke sites based on the Twenty Eleven theme, an incompatibility between certain Chrome versions and the visual editor, and an […]
- RECENT WORDPRESS NEWS ON THE WEB
I'm afraid it is a standard, in order to prevent line wrapping from breaking really long links.
is not an industry standard, and saying it is won't make it so. To me it's just an affectation that has no real val
@malkah As WordPress 4.5 has been release, this is no longer considered an Alpha/Beta issue, please do make a thread in the t
- MAY 2, 2016
WPTAVERN: BUDDYEXTENDER: A PLUGIN FOR CONFIGURING INTERNAL BUDDYPRESS SETTINGSphoto credit: Drew Patrick Miller
The BuddyPress codex has a long list of internal configuration settings that are not exposed in the plugin’s admin settings page. These are short definition lines that can be added to a site’s bp-custom.php file to make changes to BuddyPress default settings.
BuddyExtender is a new plugin from the development team at WebDevStudios that aims to make it easier for community managers to access extra configuration options. The plugin puts a dozen internal BuddyPress settings at your fingertips, including avatar sizes, autocomplete settings, the ability to disable @mentions, and more.
Once installed, the plugin can be configured at Settings -> BuddyExtender in the admin. Each setting has an explanation on the plugin’s homepage on Pluginize, WebDevStudio’s new plugin shop. Some of these settings have the ability to powerfully affect the display of your BuddyPress site, so its creators warn users to try it on a test environment before going live with their selections. The team plans to add more options to the plugin in the future. You can download BuddyExtender for free from WordPress.org.MAY 2, 2016
WPTAVERN: CUSTOMIZE POSTS PLUGIN AND SELECTIVE REFRESH ARE PAVING THE WAY FOR...photo credit: Paintbrush – (license)
Last week Weston Ruter released Customize Posts version 0.5, which includes a new framework for postmeta and the ability to preview featured images. The feature plugin aims to introduce basic content authorship in the Customizer to improve the new user site setup experience and make it easier to edit existing content.
As of 0.5, Customize Posts supports the ability to change and preview the page template, and will sync changes back to the metabox on the page edit screen. It also supports changing the post author, excerpt, and comment/ping status, with live previews and changes saved to the editor. Check out Ruter’s screencast touring the plugin’s newest capabilities:
Front-End Editing Powered by the Customizer: A Not-Too-Distant Possibility
With all these advanced editing capabilities, it doesn’t take a giant leap to imagine a future where the customizer provides the architecture for a front-end post editor. While WordPress’ front-end editor project seems to have gone dormant, improvements to the Customizer are steadily chipping away at the various aspects of content authorship that are not yet editable on the frontend.
“Now that we have the ability to selectively refresh elements without doing full page reloads, this opens the door to using these Customizer components outside of the Customizer itself, such as in the frontend,” Ruter said.
Front-end editing of partials, which are similar to customizer controls but exist in the preview, is a natural extension of the selective refresh architecture and a concept that Ruter will be exploring in the near future.
“Consider, for example, being logged-in on the frontend,” Ruter said. “You see something you want to edit and you click on it. Since the Customizer partials all have selectors associated with them, if the partials are registered with each logged-in frontend request, then there are containers that can be targeted for editing.”
Ruter envisions that clicking on an element would load the controls for that element on demand via a lazy-loaded Customizer pane or a floating control. He said that this would work in concert with customizer transactions (aka snapshots) to store the changes persistently in a transaction.
Front-end editing powered by the customizer, according to Ruter, would involve the following:
- Being able to click Customize in the admin bar to lazy-load the Customizer pane’s controls into the existing page without having to having to navigate to `customize.php`
- Being able to click on individual containers that have associated partials to start editing controls that relate to those partials
- All changes made on the frontend to be persisted in a transaction draft that is initialized on demand
The ability to edit posts in the customizer on the front-end isn’t going to happen overnight, but Ruter thinks a proof of concept could be available this year.
“It’s going to take some discovery and prototyping, similar to Customize Posts,” Ruter said. “My guess is there would be something to play around with in Q3, depending on other projects and having enough time to put down on paper these ideas that have been floating around for a couple years.”
An important step towards making that possible will be getting basic content authorship added to the Customizer, which Ruter and contributors are working towards for the upcoming WordPress 4.6 release.
These will be welcome changes for those who are looking to do more on the frontend, but it still leaves the bulk of content editing behind the admin. Unless you’re a developer who follows every update to the customizer, it’s still confusing for the average WordPress user to know what content can be edited on the frontend vs. content that requires returning to the admin. The editing experience will remain disjointed until the majority of tasks can be done on the frontend.