Category: Updates

Upgrade your site to ClassicPress 1.0.1 now!

We’ve just released ClassicPress 1.0.1, a security release.

We recommend that you update your site(s) as soon as possible.

ClassicPress 1.0.1 is a security release to match the security changes in WordPress 5.1.1 and 4.9.10 (both released today). It is available now. The new ClassicPress release also contains one minor bugfix related to WP-CLI.

You can find more information and update instructions on our forums.

As always, we’ll be around if you need any help, just make a new thread on our support forum.

ClassicPress 1.0.0-rc2 is live!

Today we’re excited to announce the release of ClassicPress 1.0.0-rc2, available immediately.

Here is a list of the minor changes in this release, as compared to our last one, 1.0.0-rc1:

  • Remove files that were accidentally included in rc1
  • Avoid duplicated rewrite rules (WordPress and ClassicPress) in .htaccess after migration
  • Remove WP-only themes features, continuing from changes in rc1 (details)
  • Add some explanatory messages for the default themes, since both parent and child themes are included (details)
  • Use a consistent header for all About tabs in the dashboard (details)
  • Fix a PHP notice in the dashboard petitions widget (details)

Next steps

Testing is critical during the RC phase – if we have any new bugs in ClassicPress 1.0.0-rc2, we need to know now so that we can get them fixed before the final release!  Otherwise, the final release will be out on Tuesday, March 5, as previously mentioned.

We invite you to put your new or existing ClassicPress sites on rc2 as soon as possible, and let us know if you see any issues, especially with regard to any of the areas that we changed.

For more information, including links to download the release, installation instructions, and a more specific list of changes, please see the release announcement on our forums.

ClassicPress 1.0.0-rc1 is live!

Today we’re excited to announce the release of ClassicPress 1.0.0-rc1, available immediately.

We have now left the “beta” release stage, and we are one step closer to a full, stable release that will serve as our foundation for many more future releases.

Here is a short list of the most important changes in this release, as compared to our last one, 1.0.0-beta2:

  • Finish porting changes from WordPress for PHP 7.3 compatibility.
  • Remove most links to WordPress.org and features that use WordPress.org accounts.
  • Fix any known bugs that are new to ClassicPress.
  • Miscellaneous other “polish” such as better organization for new files and improving the experience around ClassicPress installation and default themes.

We need your help!

Testing is critical – if we have any new bugs in ClassicPress 1.0.0-rc1, we need to know now so that we can get them fixed before the final release!  We invite you to put your new or existing ClassicPress sites on rc1 as soon as possible, and let us know if you see any issues, especially with regard to any of the areas that we changed.

For more information, including links to download the release, installation instructions, and a more specific list of changes, please see the release announcement on our forums.

ClassicPress: A Six Month Review

Did you know that ClassicPress will be six months old this month? It’s true. This month, we will celebrate six months together as an organization. It’s been a very busy six months! In addition to preparing for the launch of ClassicPress v1, we have been laying a firm foundation within the organization that will serve us well as we grow. Creating a roadmap and a more formalized organizational structure are two essential building blocks of that foundation, and we are happy to announce that they have been completed and approved by the Founding Committee.

It’s All About Community

ClassicPress is proudly a democratic community-led organization. We believe that careful planning combined with the insight and collective wisdom of the ClassicPress community will ensure the success of ClassicPress for many years to come. We want to be able to rapidly change and adapt to meet the expressed needs of the ClassicPress community. Clear roles and boundaries will help us to avoid some of the pitfalls that other organizations have experienced.

We facilitate democratic discussion and decision making via our forums, and each member has a say in how ClassicPress evolves over time by sharing and voting for ideas on our petitions website. We are sensitive to the wide variety of needs presented by ClassicPress users, and we want to ensure that those who use ClassicPress find it to be a positive experience that supports them as they focus on their own personal and business goals.

Navigating the Future

With the understanding that every organization experiences conflict from time to time, we have also created some guidelines to help navigate those challenges successfully. Ultimately, all decisions made will be an effort to serve the best interest of the organization as a whole. That has been our vision from the beginning, and we understand that it will take time and effort to make that dream a reality.

The Founding Committee is made up of many kinds of people: designers, developers, marketing professionals, security experts, plugin and theme authors, attorneys, and more. We all have a common goal — to serve the ClassicPress community by creating a powerful, versatile and predictable content management system. If you are part of the ClassicPress community, thank you for your trust, your insight, and your contributions in the forums and elsewhere! If you’ve not yet joined us, we invite you to take the time to get to know us better. We plan to be around for a very long time.

Photo by Jennie Brown on Unsplash

Can I use the ClassicPress BETA on a live website? (yes!)

WordPress 5.0 was launched today and major plugin authors are telling people not to upgrade their websites (see posts by: Yoast SEO, Advanced Custom Fields and WPML). As a result, many people want to switch to ClassicPress (a business-focused fork of WordPress) as soon as possible. The big question on everyone’s lips is: “can I use the ClassicPress BETA on a live website”?

ClassicPress itself is extremely stable. It has been tested on hundreds of sites with varied setups and our development team lead, James Nylen, has given the green light for us to say it’s safe to use in a live environment (there are no open bugs on our GitHub repository).

So the short answer to the question is YES! On a side note – I switched 55 live websites to ClassicPress as I wrote this article. Everything went perfectly!

You might be wondering why ClassicPress is still in BETA if this is the case. The answer is simple – there are a few things we need to do before launching v1. Specifically:

  • There are a few dashboard areas we still need to convert to being ClassicPress focused rather than WordPress focused (for example, we’re adding a Petitions dashboard widget)
  • There is still the occasional mention of WordPress instead of ClassicPress, such as in the README file
  • Localisation is incomplete

If you would like to switch to ClassicPress, migration is extremely simple – you can download and install our migration plugin which will do the hard work for you (always make a backup first!).

Please note:

  • Please make a backup of your site – ClassicPress cannot be held responsible for any issues that may arise from installing BETA software
  • There is one plugin that is unhappy with a ClassicPress installation: Wordfence (and for good reason – Wordfence is a security plugin and one of its functions is to detect whether core files have been modified, which of course ClassicPress has done). Please let Wordfence know that you would like ClassicPress compatability!
  • There are two plugins which conflict with our migration plugin: Disable WP Core Updates Advance and WP Config File Editor. Please disable these plugins if you’re migrating your site.

Ready? We are!

A new dawn – announcing “Sunrise” the first alpha release of ClassicPress

Get the download links »

After hundreds of hours of intense work by dozens of volunteers, we’re extremely excited to announce the first alpha release of ClassicPress, codenamed Sunrise. This launch has been a work of sheer dedication, a sprinkling of love, a dash of frustration and a large helping of teamwork, collaboration and enjoyment.

 

We need your help to test what we’ve built!

There are two specific parts to the alpha launch that need to be tested:

  • ClassicPress
  • The ClassicPress migration plugin, which switches a WordPress site to a ClassicPress site

 

Found an issue?

If you find any bugs or issues, please create an issue on the relevant Github repository:

You are also very welcome to join our Slack channel to chat with the teams – the channels to be aware of are #testing#core and #migration.

 

Security issues

If you find any security issues, please disclose them by emailing [email protected] – please do NOT share them publicly, either on Slack or Github.

 

On a personal note…

I would like to say a HUGE thank you to everyone who has been involved in this process. Words cannot describe how thankful I am to all of you – I’m constantly humbled by the time, effort and passion that people have dedicated to ClassicPress. What started as a protest quickly turned into a movement, and that movement has grown to countless volunteers in just a few months. Without you, none of this could have been a reality. With you, we’ve got an extremely bright future and a path towards delivering a world-class product to businesses who want to have a powerful, versatile and predictable solution for their website needs.

– Scott Bowler

Theme and Plugin Compatibility with ClassicPress

A lot of people have heard of ClassicPress by now and although many are not opposed to the idea of a hard fork, the idea that plugins and themes will no longer work is worrisome. The main and real question is: how much and for how long will my theme and plugins continue to work on a different platform such as ClassicPress?

If a plugin or theme works with WordPress 4.9.x, it will work with ClassicPress 1.x for as long as the 1.x releases are supported. If you’re seeing something otherwise, please help us fix it by reporting a bug.

Longer-term, compatibility will depend on the specific differences between ClassicPress v1 and v2. We can understand that people have reservations. And it is difficult for us to say exactly what will happen, because we also don’t know that yet. However, we can say confidently that we will do our best not to break sites with any upgrades, and give people time to opt in to new features 🙂

We think that for the time being (two years at least), big players in the plugin and theme space will want to keep backward compatibility. As long as the Classic Editor plugin is being “promoted” as an alternative, these plugins should remain working for installs that run Gutenberg and installs that do not, which means these plugins can also be used on ClassicPress.

[UPDATE:] On November 7, 2018 Gary Pendergast of WP Core announced that the Classic Editor plugin will be officially supported until December 31, 2021. This automatically implies that plugin- and theme authors will want to keep their software functional on the classic editor too, which in turn means that said plugins/themes can be used on ClassicPress.

At the moment we are working hard towards our initial release. Once v1 is out the door, we will start talking with plugin developers to see what can be done to make ClassicPress compatibility smoother. By the time the classic editor plugin is no longer supported by WordPress, we believe there will be a robust ClassicPress theme and plugin market that attracts the best designers and developers, and serves the business market we focus on. You can bet we’ll be working hard to bring that about.

If any plugin and/or theme developers are reading this, we encourage you to get in touch with us via Slack.

Project management planning: initial meeting

Today a few of us had a Zoom call about our strategy for project management in ClassicPress, including how we can better organize our open issues list to reflect progress and show others where they can contribute.

As always, remaining to-do items from this meeting are marked in green.

Thanks to Patrice Embry for joining us and helping us plan our project management strategy, with the goals of making it easier for people to see what state the project is in, while not adding too much extra work for developers.

We started by looking at an issue on the APIs repository and its linked issue on the ClassicPress repository.  We decided that neither of these issues was actionable as-is, so I’ve closed them both with a progress update and split out remaining items into smaller issues.

We also realized that we need better organization and discoverability for our project board.  If you’re on the main ClassicPress repository, the “Projects” tab used to say “0 Projects” because the project is actually under the ClassicPress organization (one “level up” on GitHub).  This is good, because it allows us to accumulate tasks from multiple repositories into the same board, but it wasn’t very easy to figure out what was going on.  For now, I’ve added a “dummy” project board that just links back to the real one:

Patrice volunteered to write up a proposed workflow for working on GitHub issues.

Once we have something written up for this, we’ll put the guide on docs.classicpress.net as part of a larger guide for contributing to the project.

I went through all open issues on the ClassicPress repository and assigned a milestone (v1.0.0-alpha1, v1.0.0-beta1, or v1.0.0) to most issues, and all the rest either have an “action label” like close (recommend for closing), or a request for clarification or next steps.

On the project board, Patrice will split the “To Do” column into “Backlog” and “Current Sprint” so that we have a better view of what is actually up next (what we are currently focused on). The items in “Current Sprint” should be pretty closely correlated with our “current” milestone. We’re not planning to use a strict scrum-like sprint structure, but the “Backlog” vs “Current Sprint” split on the project board can be updated approximately every 2 weeks.

This is a volunteer project, and I’m sure that our project management strategy will continue to evolve.  Please join us in Slack to help!

Committee Meeting: The one with the orange

Date/time: 9th October 2018, 5pm – 6.29pm UTC

Todos marked in green.

Committee members present (alphabetical by surname)

  • Pieter Bos
  • Scott Bowler
  • Fredrik Forsmo
  • Rui Guerreiro
  • Ray Gulick
  • Tim Kaye
  • Charles Lecklider
  • James Nylen
  • Daniele Scasciafratte
  • Wade Striebel
  • Dustin Snider
  • Fabian Wolf

Transcript

Available via Slack. Click to jump to meeting start point.

Focus of meeting

The agenda contained the following topics

  1. Team updates
  2. Deadlines for launch
  3. Role of the community team (incl. suggestions opened on Github as issues)
  4. Decision on plugin installation screen for v1 (https://github.com/ClassicPress/ClassicPress/issues/117)
  5. Process in a nascent project
  6. Orange

Outcomes

1. Team updates

A lot of ground covered, a few todos appeared:

  • Marketing; need to update the tagline on the Github repo – Pieter Bos has volunteered
  • Fundraising: Look to get initial sponsorship from plugin developers
  • Community: Requires more volunteers – marketing to promote

2. Deadlines for launch

To be confirmed by October 31st.

3. Role of the community team

  • Community to put together process for handling community discussions that originate on Github
  • #marketing and #community to meet to define a process for reaching out to potential volunteers
  • first responders to issues on Github should focus on getting the issue in front of the right people

4. Decision on plugin screen tabs (popular, featured etc)

Deferred – requires more discussion

5. Process in a nascent project

This topic ended up being linked to the “Role of the community” topic.

6. Orange (colour of new site design)

This ended up going off on a tangent. Housekeeping for next time: topics which should be decided at a team level should not be added to the committee meeting agenda.

Other Business

invisnet: I’d like to add one final item to the agenda: that the agenda for the next meeting has sufficient detail per item that we don’t end up disappearing down the rabbit hole again as we’ve done twice in this meeting?

Post-committee meeting note from Scott Bowler: This was our second committee meeting, and there are still teething problems. We need to make sure the committee agenda is clear and topics which should be decided at a team level should not be added to the committee meeting agenda.

Committee Meeting: The one with the tagline

Date/time: 26th September 2018, 5pm – 5.48pm UTC

Todos marked in green.

Committee members present (alphabetical by surname)

  • Pieter Bos
  • Scott Bowler
  • Fredrik Forsmo
  • Rui Guerreiro
  • Tim Kaye
  • James Nylen
  • Daniele Scasciafratte
  • Wade Striebel
  • Dustin Snider
  • Fabian Wolf

Transcript

Available via Slack. Click to jump to meeting start point.

Focus of meeting

The agenda contained the following topics

  1. Tagline proposal: “ClassicPress: No Gutenberg. Great future!”
  2. Team definitions and team leaders
  3. What/how for documentation. I just saw readme.io was approved, so let’s discuss the next steps.
  4. Define Slack Premium status (we are reaching the 10000 limit)
  5. Code style for project
  6. Quality assurance
  7. Charles Lecklider has requested to join the committee. Scott Bowler is nominee.
  8. Keeping track of volunteers

Outcomes

1. Tagline proposal: “ClassicPress: No Gutenberg. Great future!”

Approved for v1. A new tagline will be prepared for v2.

2. Team definitions and team leaders

The following teams and team leaders were decided:

  • Development led by James Nylen
  • Security led by James Nylen
  • Community led by Dustin Snider with support from Pieter Bos and Wade Striebel
  • Marketing led by Scott Bowler
  • Documentation – Dustin Snider to ask Pat Dumond to be Team Lead
  • Fundraising led by Scott Bowler
  • QA led by Rui Guerreiro

3. What/how for documentation.

We have been approved for an open source license of readme.io. The Community team will discuss the next steps and submit a proposal for documentation.

4. Define Slack Premium status (we are reaching the 10000 limit)

Slack Premium costs more than the project can afford. In order to get Premium for free we need to be a registered charity. To become a registered charity in the UK we need annual pledges of at least £5,000.

Scott will ask Slack for an exception whilst we get to this status.

5. Code style for project

WordPress Coding Standards will be used for version 1 and the topic will be revisited for v2.

6. Quality assurance

It was agreed that Rui Guerreiro will put a plan together for Quality Assurance.

7. Charles Lecklider has requested to join the committee. Scott Bowler is nominee.

Approved.

8. Keeping track of volunteers

It was agreed that the Community Team will put together a plan for keeping track of volunteers, most likely using the ClassicPress membership system.

Other Business

The idea of ClassicPress gigs (a jobs board where only contributers can apply for jobs) was raised by Scott Bowler in the community channel. Rui Guerreiro suggested this topic be discussed. There was a general consensus that providing Contributors with “perks” was a good idea and that the Community Team would explore ideas further.