ClassicPress Blog

Posted on January 15, 2020January 15, 2020 by Elisabetta Carrara | Category: Tutorials

We have discussed before how to move an existing site into Softaculous here. But how do you install a new site? Easy! Here’s how.

BEFORE INSTALL: Make sure your hosting supports PHP 7.0 and above, recommended when installing ClassicPress

Step 1: Getting started

Open Softaculous and search for ClassicPress in the search bar, then open the ClassicPress summary page – As you can see there is an option to install:

There are two install methods, Quick Install and Custom Install:

Below, choose the appropriate step 2 for Quick or Custom.

Step 2: Quick Install

As you can see from the screenshot below, the only information required for this method are Domain, Installation Folder and Admin Account

After entering the info just hit the install button at the bottom of the page and you will be redirected to:

SUCCESS!! You have installed ClassicPress from the Softaculous installer!

Step 2: Custom Install

The Custom Install is recommended for advanced users who need more set up options.

Just select Custom Install from the drop-down and you will be redirected to this:

Here you can fill in Software Setup, Site Settings, Admin Account and Advanced Options (DISCLAIMER: this is a test site, created on a testing free hosting, options shown may vary according to the settings your hosting allows for Softaculous), then all you need to do is hit the Install button at the bottom of the page, and you will be redirected to this:

SUCCESS!! You have installed ClassicPress from Softaculous installer!

Posted on January 15, 2020January 14, 2020 by Patrick Klein | Category: Tutorials

A while ago we explained how to import your existing sites into Installatron in this article. In this post I will give a step by step tutorial for how to install a new site.

BEFORE INSTALL: Make sure your hosting supports PHP 7.0 or above, recommended when installing ClassicPress

Step 1: Getting started

Navigate to the Application browser of Installatron.

Once there, select the ClassicPress icon.

Click “Install this application” in the right corner.

Step 2: Settings

Now, fill in the Location and Version.

Under Location you fill in the Domain name you want to use and optionally the directory in which you want ClassicPress to be placed.

Under Version you pick the ClassicPress Version, Language and Automatic Update settings. If you are not sure what update setting you should pick, “Update new minor versions and security releases” is probably the one you need.

After this you need to fill in the Settings and Advanced settings.

Under Settings you chose your admin’s Username, Password and Email. You also pick your site’s Title and Tagline.

After this you can decide wether you want to fill in the Advanced settings yourself or let Installatron do it for you. If you let Installatron do it, you can now click on “Install” and go to Step 3, otherwise go to Step 2½.

Step 2½: Advanced settings

In the Advanced settings you can configure some extra settings for your ClassicPress installation like Database, Notifications and Backups

Under the Database settings you can fill in an existing database. Fill in the username and password to give Installatron access. It also allows you to pick a prefix for your table. You do not need to change this, but it is helpful to change it to something unique if you are already running other ClassicPress sites from the same Database.

The other Advanced settings allow you to pick what email notifications to receive, where automatic back-ups are stored and how often back-ups should be made.

When all of this has been filled in, you can click “Install”.

Step 3: Wait

Now simply wait for this progress bar to fill up

Once the above turns into:

You are done. Congratulations, Now get to work!

Posted on October 30, 2019January 10, 2020 by ZigPress | Category: Tutorials

Here’s a quick tip for ClassicPress theme developers. If you want to remove all trace of the WordPress/ClassicPress built-in emoji scripts, styles and tags from your ClassicPress site’s pages, here is the code that you need to add to your theme’s functions.php file:

remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('admin_print_scripts', 'print_emoji_detection_script');
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('admin_print_styles', 'print_emoji_styles');
add_filter('emoji_svg_url', '__return_false');

This code should be added near the end of your functions.php file (but before the final ?> if there is one).

The last line was not needed for WordPress sites, but is needed for ClassicPress. It prevents the site outputting a DNS Prefetch tag for the ClassicPress emoji subdomain, and therefore simplifies your GDPR disclosure obligations slightly.

ClassicPress version 2 should remove this fairly useless functionality altogether by shifting it to a core plugin. If you’d like to make sure it does, you can upvote the petition.

This tutorial was originally published on ZigPress.com. The original post can be found here.

Posted on October 23, 2019October 16, 2019 by Patrick Klein | Category: Tutorials

Internationalization, or i18n as it’s often abbreviated, is an important part of many projects. That is why we want to highlight a course made by Ian Grieve of azurecurve. In this course Ian will take you through the process of translating plugins (and themes) step by step.

Ian introduces his new series as follows:

“I started using WordPress when I launched this blog back in 2011 and a couple of years later started writing plugins to add missing functionality. At the end of last year I switched over to ClassicPress, a hard-fork of WordPress.

As part of my transition to ClassicPress I created new versions of my plugins which added new functionality and improved security. I had already done some work to internationalize my plugins, but took the opportunity to improve this aspect as well.

Having done so, I thought that a series on how to internationalize and localize plugins might be a useful thing to write; while the series is targeted at plugins, as I am a plugin author, the principles are the same for themes.”

Where do I start?

If you want to get serious about creating plugins or themes for ClassicPress, i18n is not an afterthought, but should be regarded as a requirement. In this context, azurecurve’s new course should be an invaluable resource.

Excited to get started? You can find the series index here.

Posted on October 16, 2019September 25, 2019 by John Alarcon | Category: Tutorials

A common recommendation in the WordPress world when you’re having issues with a plugin is to disable all plugins. Don’t do it!

While we can employ best practices in our own code, we have no control over what other developers are doing. As a result, plugin conflicts will sometimes happen. What’s more, another developer’s plugin might be causing the issue, while it is my plugin that actually exhibits the symptoms.

When these types of issues arise, the most common thing a developer will recommend is to deactivate all your plugins, set your theme to TwentyWhatever, then try their plugin again. While this has been the standard advice for a decade, this is often a waste of time. There’s a better way.

About Deactivating Plugins

Consider what happens when you deactivate a plugin. Do you actually know? Yeah, me neither. Other than the plugin no longer working, it may not be clear what has changed. Were options deleted? Were settings lost? Is the site still working? The answer is: it’s up to each and every plugin developer, so, who knows.

Unless you dig into the code of each plugin, you never really know what may happen when you deactivate them. You just might get stuck having to reconfigure a bunch of plugins. This is why it is preferable to not deactivate all plugins as a first course of action – you just don’t know what may be lost. So, instead of deactivating all plugins at once, I take a more thoughtful approach to make the best use of my time.

Conflict Resolution Plan

The steps listed here will seem logical once you’ve gone through them. Indeed, they will probably even seem obvious once they’re pointed out.

1. Do not disable any plugins or change the theme.
2. Make a shortlist of any plugins that you think might be related to the conflict.
3. Deactivate the first plugin on your shortlist and check to see if the conflict persists.

Does the conflict persist?

If so, reactivate that plugin and then repeat (step 3) with each plugin on your shortlist.

Is the conflict resolved?

If so, you now know which plugin is conflicting. There is usually no need to deactivate any remaining plugins.

If processing through your shortlist of suspected plugins does not reveal the conflict, start at the top of the main plugin list and repeat the process – deactivate, check for conflict, reactivate – until you find the conflicting plugin.

Wrapping Up

Deactivating all plugins in one quick action can be tempting when plugin conflicts arise, but, it’s often unnecessary. Without knowing exactly what every plugin does upon activation, it is very much a “shot in the dark” that mass-deactivation won’t actually create more work. Your gut instinct (which then becomes your shortlist) is often a very quick way to conflict resolution, and, if not, you have a more systematic approach to determine just where that conflict lies.

What do you think?

Are you in support of a thoughtful approach, or would you just deactivate them all and hope for the best? Have you ever had anything unexpected happen when you deactivated a plugin? I have my own opinion about what a plugin should do upon activation, but, what do you think? I’d love to hear your thoughts – let me know in the comments!

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.

Posted on October 9, 2019October 14, 2019 by Patrick Klein | Category: Tutorials

If you use an installer you might have never actually looked into the wp-config file. Many people will tell you that it is probably one of the more important files in your ClassicPress installation to understand. This is because there are so many things that it can do to cause problems if used incorrectly. That is why I want to take some time to decipher it piece by piece for people who might be intimidated by all the code. This explanation follows the base wp-config-sample.php of a clean install. Things might be added, out of order or missing in your production site. Just because there is something in your file that is not discussed here does not mean it is bad, but try to make note of these. When you are having problems you can then look if removing these unknown lines is the solution.

The database settings

The first and, arguably, most important part of the wp-config file are the database settings. It’s important that all six of these are filled in correctly or you might run into trouble with your database.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for ClassicPress */
define('DB_NAME', 'database_name_here');
/** MySQL database username */
define('DB_USER', 'username_here');
/** MySQL database password */
define('DB_PASSWORD', 'password_here');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

What do they mean?

define('DB_NAME', 'database_name_here');: This is the name of your database. This is often automatically generated by your hosting. This is basically just what your database is called.
define('DB_USER', 'username_here');: This is the username of your database. This is different from your database name, even though a lot of hostings use the same name for both. The username is a distinct login to gain access to your database.
define('DB_PASSWORD', 'password_here');: This is the password of the username from above. To login, ClassicPress needs the password belonging to the username you’ve chosen.
define('DB_HOST', 'localhost');: This is the location of your database. For a lot of people this will be Localhost. But in the rare cases that a database is in a seperate location from the ClassicPress installation, the correct ip-adress can be filled in here.
define('DB_CHARSET', 'utf8');: This is the set of characters that the database uses. The standard value is utf8 and is in almost all cases the correct one. Utf8 supports all languages, and as such is the most ideal value.
define('DB_COLLATE', '');: This is the specific subset of charset that your database should use. Do not change this unless you’re absolutely certain.

The security keys

Underneath the database settings, you have the security keys. These consist out of four secret keys and four salts. In very simplified terms, these keys make it harder to break your security barriers. The four salts further complicate your defenses. While the keys are nessecary, the salts are not, but it’s still recommended to use them!

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Your keys are not something you have to remember so make them as long and complicated as possible. You can also use one of the many online key generators.

The table prefix

The next important line of code is the table prefix. What this does is tell ClassicPress what the prefix of your table is. That is not very surprising, but what is the prefix of a table?

$table_prefix  = 'cp_';

In your database there will be several characters in front of the table name, usually cp_ or wp_. But you can change this during installation. Do not change this value after installation or you will break your database!

The debug settings

Under the table prefix is the debug setting. This decides if errors are logged or not. Set this to false to hide errors

define('WP_DEBUG', false);

If you set this to true you can also add extra lines to decide how exactly the errors are logged.
define( 'WP_DEBUG_DISPLAY', true );: Insert this line to enable display errors in text on the browser. Or change true to false to hide these errors.
define( 'WP_DEBUG_LOG', true );: Insert this line to enable an error_log file that you can access through FTP or your file manager. Or change true to false to block this feature. You can also change true into a path to add these logs to a specific file. For example: define( 'WP_DEBUG_LOG', '/error/cperrors.log' );

The directory settings

The final two settings can usually just be left alone. They are there to help ClassicPress find its settings.

/** Absolute path to the ClassicPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');
/** Sets up ClassicPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

The first part will define the ABSPATH. But what is the ABSPATH? Simply said it is a map for ClassicPress to find its own main folder. An absolute path to the main folder. The second setting will then use this ABSPATH to tell ClassicPress where it can find wp-settings.php.

Extra settings

Of course this is not everything that wp-config.php can do. There are many more settings for all kinds of objectives. If you want to use some of these, simply copy and paste them between WP-DEBUG and ABSPATH. Some of the more interesting of these are:

WP_SITEURL and WP_HOME

Using define( 'WP_SITEURL', 'http://example.com/classicpress' ); you can change the location of your ClassicPress installation without changing your home url. Simply use your main URL and then / with the name of the folder that you placed ClassicPress in. This overrides the option from settings in your CMS.

define( 'WP_HOME', 'http://example.com' ); can be used in combination with the above to change the home URL to keep it at root level or to change the homepage to a / something. It can also be used to force https or a main url when your domain has aliases. This also overrides the option from settings in your CMS. This makes sure that it can’t accidentally be changed by another user.

Moving directories

You can move several directories into seperate folders. These are uploads, themes, plugins and/or the entire wp-content folder. You can use the following settings for this, simply changing the relative URL:
Wp-content: define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content' );
Plugins: define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/plugins' );
Uploads: define( 'UPLOADS', '/wp-content/uploads' );

But what about themes?

Themes are a little more complicated. The theme folder is hardcoded relative to the wp-content folder. But what you can do is register an extra themes folder using:
register_theme_directory( dirname( __FILE__ ) . '/themes' );

Cache

Using define( 'WP_CACHE', true ); you can turn ClassicPress’ advanced caching features on. You can also turn them off using define( 'WP_CACHE', false );.

Core updates

You can use the auto core update settings to decide how your ClassicPress installation should deal with updates. There are three settings:
define( 'WP_AUTO_UPDATE_CORE', false );: This turns off all automatic updates.
define( 'WP_AUTO_UPDATE_CORE', true );: This turns on all automatic updates.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );: This turns on all minor automatic updates but will not do major updates automatically. This is the default.

PHP memory limit

There are a lot of errors that occur related to php memory limit. And while its better to change this in php.ini, not everyone has access to this. You can use wp-config to define a limit using: define( 'WP_MEMORY_LIMIT', '64M' ); This does not always work as some hosting providers block this.

Wrapping up

All in all, you can do a lot of stuff with this little file that most people ignore after installation. There is also a lot that I haven’t even mentioned yet! I hope that this article has given you a bit more insight if you were unfamiliar with using the config. Of course with this power comes a lot of responsibility and I advise against experimenting on a production site because you can also break a lot here. Please be careful and quoting the wp-config file: /* That's all, stop editing! Happy blogging. */. Well actually ‘start editing responsibly’. 😉

Posted on September 12, 2019September 24, 2019 by John Alarcon | Category: Tutorials

A static dashboard widget is a great way to share information, important links, or action items with your clients when you hand-off a site. Very little code – very high user impact!

When handing off a ClassicPress website to a client, do you provide them with information or links to get them off to a good start? A static widget in the dashboard – just like the one pictured below – is a great solution for this! Wouldn’t it be cool to add something like this to the client’s dashboard? Well, we’re going to build it shortly.

Depiction of a Static Text Widget

The image above depicts what we’ll be creating here today. However, before moving on, let’s make a few quick distinctions about widgets, shall we?

Static Widgets vs Dynamic Widgets

Whereas a dynamic widget shows content that changes over time, such as latest posts or recent comments, a static widget shows the same content always. In the image above, the widget is simply inviting the user (ie, your client) to contact their project manager.

Of course, this is just a simple example of how you might use a static widget. Indeed, you might want to include your business address, hours of operation, helpful links, payment info, or any of those other things that you might typically include in a hand-off document.

Dashboard Widgets vs Front-end Widgets

One last distinction to make before starting this project is the difference between dashboard widgets and front-end widgets. It’s simple, but, bears repeating.

Dashboard widgets will appear in the main dashboard view. The site admin can collapse and expand the widget, as well as move it to a new position, or even hide it altogether.

Front-end widgets are those that are displayed to visitors on your site. Visitors cannot usually expand or collapse front-end widgets (although there are exceptions,) but, they will not likely be able to move or hide the widget content.

Where to Place the Code?

If you’re coming from the WordPress space, you will be familiar with placing code into your theme’s functions.php file. This is the “old school, quick ‘n dirty” way, and is no longer recommended. The code in this tutorial should be placed into an utility plugin. If your site already has a utility plugin, great, you can just add the code below to that plugin. If you don’t yet have such a plugin, go build one. I’ll wait for you here.

The Process of Creating a Static Widget

To create a dashboard widget, three objectives must be achieved. The three objectives are to:

1. create a function that prints the widget content, and
2. create a function that registers the new widget in the system, and
3. use an action hook to specify when the widget should be registered.

Let’s work through these objectives now. Move through the following steps, adding the code examples to your utility plugin. There’s no need to make customizations as you go – let’s just get it working first and fine-tune later.

1. Print the Widget Content

This simple function populates the widget with your content. As you can see, PHP tags are used in the function to allow for neater HTML markup. Add the code to your utility plugin.

function codepotent_display_static_dashboard_widget() {
    ?>
 
    <h1>Hey, it worked!</h1>
 
    <?php
}

2. Register the New Widget

This function registers the widget in the system by calling the wp_add_dashboard_widget function with several arguments. These arguments tell the system your preferred id and title for the widget, as well as the name of the function that will ultimately output the widget content (from step 1 above.) Add the code to your utility plugin.

function codepotent_register_static_dashboard_widget() {
    wp_add_dashboard_widget(
        'my_static_dashboard_widget', // your own custom widget id
        'My Widget', // the widget box title
        'codepotent_display_static_dashboard_widget' // function that displays content
        );
}

3. Hook the New Widget in at the Right Time

In case you didn’t notice, those functions created in Steps 1 & 2 aren’t actually called anywhere. Yet. If they aren’t called, they can’t run. That’s where an action hook comes into play. The action hook tells the system exactly when to run the function that registers your widget, which, in turn, tells the system which function to use to display the content. Now, that was a lot of words, but, it really just boils down to a single line of code that says “run this function during the wp_dashboard_setup action.” Add the line to your utility plugin.

add_action('wp_dashboard_setup', 'codepotent_register_static_dashboard_widget');

Verify your Work

With the above objectives out of the way, take a moment to verify your work. Head over to the dashboard and find that you now have a new widget showing in all its glory. Collapse it. Expand it. Move it around. Hide it. It should work just like every other widget in the dashboard.

Initial Static Text Widget

Add Meaningful Content

With the widget now displaying in the dashboard, you can revisit the display function (from Step 1) and flesh it out with whatever content you like. In the final example below, I’ve combined the code from above and added some additional markup to make the widget look like the original example image.

// Step 1
function codepotent_display_static_dashboard_widget() {
    ?>
    <div style="display:grid;justify-content:space-between;grid-template-columns:repeat(auto-fit,minmax(48%,1fr));grid-template-rows:1fr;grid-gap:20px;">
        <div>
            <img src="https://codepotent.com/wp-content/uploads/2019/07/kelly-marks-avatar.jpg" style="border:1px solid #ccc;padding:2px;">
        </div>
        <div>
            <h2>Kelly Marks</h2>
            Your project manager, <strong>Kelly Marks</strong>, is committed to your success! If you need anything at all, drop Kelly a line!
            <ul>
                <li>(123) 456-7890 x 123</li>
                <li><a href="#">[email protected]</a></li>
            </ul>
        </div>
    </div>
    <?php
}
 
// Step 2
function codepotent_register_static_dashboard_widget() {
    wp_add_dashboard_widget(
        'my_static_dashboard_widget', // your own custom widget id
        'My Widget', // the widget box title
        'codepotent_display_static_dashboard_widget' // function that displays content
        );
}
 
// Step 3
add_action('wp_dashboard_setup', 'codepotent_register_static_dashboard_widget');

Extra Credit

The example above will show the widget to anyone who has access to the main dashboard. Can you think of a way to show the widget to only admin users? Or, how about limiting it to just a single user? I think you can figure it out!

Wrapping Up

Adding a static widget to the ClassicPress dashboard is actually quite easy. There’s no need to add a whole plugin just to show some information in the dashboard. With very little work, you can create your own great-looking dashboard widgets and show your clients that their site is on your mind. Add text, links, images – or anything else that might be helpful to your clients!

What do you think?

Did you realize dashboard widgets were so easy to create? Have you been using a plugin and are going to switch to this method instead? What other things might you include in a dashboard widget? I’d love to hear your thoughts – let me know in the comments!

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.