Move WordPress Root Directory Files Safely

Glowing folders move toward a central root directory beside a server rack.

If you’re searching for how to move WordPress root directory files from /blog to the main domain, the process is easier than it first appears. You need a full backup, access to your hosting files, and the right URL changes in WordPress.

The basic order matters: back up the site, move every WordPress file into the document root, update both WordPress URLs, refresh permalinks, and test every important page. We recommend taking your time here. A careful move protects your content, rankings, forms, and customer experience.

Why Move WordPress From a Subfolder?

WordPress often starts in a folder such as public_html/blog, while visitors access the site at example.com/blog. That setup works, but it may not fit the way you want your business website to appear.

Moving the installation to the root changes the public address to example.com. Your homepage no longer includes the subfolder, and new pages use cleaner paths such as example.com/services instead of example.com/blog/services.

The move can make your site structure easier to manage, especially if WordPress is the main website on the domain. It can also remove confusion when you share links, set up analytics, or connect marketing tools.

WordPress files and the public website address are connected, but they aren’t the same thing. The official WordPress directory guide explains how WordPress files can live in one location while visitors see another URL.

Before you change anything, confirm that the root folder is the right destination. Depending on your hosting account, it may be named public_html, www, htdocs, or a folder linked to the domain.

Prepare the Site Before You Move Anything

A WordPress move is a file and URL change, not a new installation. Your database usually stays where it is. Still, we recommend preparing a complete copy of both the files and database before touching the live site.

Export the database through your hosting control panel, phpMyAdmin, or your regular backup system. Download the entire WordPress directory too, including wp-content, wp-admin, wp-includes, wp-config.php, .htaccess, and hidden files.

Keep the backup somewhere outside your hosting account. If a failed move damages the live files and the only backup sits on the same account, recovery becomes much harder.

Laptop showing a website structure diagram on a modern desk.

Before continuing, write down these details:

Record the current WordPress Address and Site Address under Settings > General.
Note your database name, database user, table prefix, and hosting login.
Check whether the root folder already contains another website or an index.php file.
Clear or pause caching while you work, including plugin, server, and CDN cache.
Schedule the move during a quiet period if the site receives orders, bookings, or contact requests.

If another website already occupies the root directory, don’t move WordPress over it. Make a separate plan for that site first, or ask your host to confirm which folder belongs to your domain.

How to Move WordPress Root Directory Files

Once your backup is ready, open your host’s File Manager or connect through FTP. cPanel users will usually find the tool inside cPanel. Other hosts may use a custom panel with similar file controls.

Open the folder where WordPress currently lives. For example, it might be public_html/blog. Then move the files inside that folder into the domain’s document root.

A computer screen showing folders in a dark file manager interface.

Follow this sequence:

Open the WordPress subfolder and select everything inside it.
Include hidden files, especially .htaccess, if your file manager hides them by default.
Choose Move, then set the destination to the root folder, such as public_html.
Confirm that folders including wp-admin, wp-content, and wp-includes now sit directly inside the root.
Check that index.php, wp-config.php, and .htaccess are also in the root.
Leave the old folder in place until the new site works correctly.

Don’t move only the wp-content folder. Don’t copy only index.php unless you’re deliberately using a different WordPress directory setup. A full move needs the complete WordPress file set.

If the file manager asks whether to overwrite an existing file, stop and check what is already in the destination. Overwriting a live site’s index.php or .htaccess can take down another website. The manual WordPress subfolder migration guide also covers file transfer options through hosting tools.

Update Both WordPress URL Settings

After the files reach the root, open the WordPress login page at the new address, usually:

https://example.com/wp-admin

If WordPress redirects you back to the old subfolder, use the recovery options below before trying again.

In the dashboard, go to Settings > General. You should see two fields:

WordPress Address (URL) points to the location of the WordPress core files.
Site Address (URL) controls the address visitors use to reach the website.

For a full move to the root, remove the subfolder from both fields. Change:

https://example.com/blog

to:

https://example.com

Save the changes. WordPress may log you out and send you to the new login address. That’s expected.

Both URL fields must point to the same final domain when all WordPress files have moved into the root. Changing only one field can create redirects, missing styles, or login problems.

If you can’t reach the dashboard, add or edit the URL constants in wp-config.php with your hosting File Manager. Use the final root address for both WP_HOME and WP_SITEURL. If those constants already exist, edit them instead of adding duplicates.

Another recovery option is phpMyAdmin. In the WordPress options table, update the home and siteurl values to the root domain. The table may have a custom prefix, so don’t assume it is named wp_options.

Refresh Permalinks and Replace Old URLs

Once the new root URL works, go to Settings > Permalinks and click Save Changes. You don’t need to change the permalink structure. Saving the page refreshes WordPress rewrite rules and often fixes broken page URLs.

The main URL settings don’t update every old reference stored in your database. Images, menu links, buttons, plugin settings, and post content may still contain /blog.

Run a search and replace for the old full URL and the new root URL. Use a WordPress migration tool or a command that understands serialized data. A basic database-wide text replacement can damage serialized settings, so don’t run a blind SQL replacement.

The WordPress subdirectory installation guide provides helpful context on the relationship between directory paths and public URLs. That distinction matters when you repair old links after the move.

Search for both versions of the old address:

https://example.com/blog
http://example.com/blog

If your site recently switched to HTTPS, check for both protocols. Replace old paths in menus, widgets, theme settings, forms, and SEO plugin fields.

Test the Site Before Removing the Old Folder

A homepage loading correctly doesn’t prove the move is complete. Test the site as a visitor and as an administrator.

Open a private browser window, then check:

The homepage and several pages
Blog posts, categories, and tags
Images, PDFs, and downloadable files
The new /wp-admin login
Contact forms, checkout pages, and newsletter forms
Navigation menus and footer links
Search results and pagination
SSL security and browser warnings
XML sitemap and robots.txt
Caching and mobile layouts

If pages show 404 errors, save the permalink settings again. If images are missing, check their URLs in the database and media library. If the site redirects repeatedly, review the URL fields, wp-config.php, caching rules, and .htaccess.

You should also create 301 redirects from the old subfolder URLs to their new root paths. For example, an old /blog/contact address may need to redirect to /contact. Test a few old URLs manually before adding a broad rule.

Don’t delete the old subfolder immediately. Keep the backup and old files until you’ve confirmed that important pages, forms, and search traffic work normally.

Move to Hosting That Makes WordPress Easier

A directory move is also a good time to ask whether your current hosting makes routine WordPress work harder than it should.

At ZADiC, our cPanel and WordPress hosting gives you familiar file tools, one-click setup, free SSL on many plans, security monitoring, and 24/7 human support. That means you can handle a move with clear access to your files, or get help when a redirect or database issue appears.

If your site is growing, managed Web Hosting Plus and VPS options provide more room for traffic, plugins, and business tools. You don’t need to wait for a major outage to choose a more dependable setup. Good hosting gives you a stable place to build, update, and grow.

Keep the Move Clean and Controlled

To move WordPress from a subfolder to the root, back up the files and database first. Then move the complete WordPress installation into the correct document root, update both URL settings, refresh permalinks, replace old subfolder references, and test the site carefully.

The most common mistakes are simple: moving only part of the installation, overwriting another site, changing one URL instead of both, or skipping the database search and replace.

Take those risks out of the process, and the move becomes a controlled change instead of a stressful rebuild. A reliable host and a complete backup give you the confidence to put your WordPress site where it belongs.

Submit a Comment Cancel reply

What's New?

WordPressMove WordPress Root Directory Files SafelyIf you’re searching for how to move WordPress root directory files from /blog to the main domain, the process is easier than it first appears. You need a full backup, access to your hosting files, and the right URL changes in WordPress. The basic order matters: back up the site, move every WordPress file into the document root, update both WordPress URLs, refresh permalinks, and test every important page. We recommend taking your time here. A careful move protects your content, rankings, forms, and customer experience. Why Move WordPress From a Subfolder? WordPress often starts in a folder such as public_html/blog, while visitors access the site at example.com/blog. That setup works, but it may not fit the way you want your business website to appear. Moving the installation to the root changes the public address to example.com. Your homepage no longer includes the subfolder, and new pages use cleaner paths such as example.com/services instead of example.com/blog/services. The move can make your site structure easier to manage, especially if WordPress is the main website on the domain. It can also remove confusion when you share links, set up analytics, or connect marketing tools. WordPress files and the public website address are connected, but they aren’t the same thing. The official WordPress directory guide explains how WordPress files can live in one location while visitors see another URL. Before you change anything, confirm that the root folder is the right destination. Depending on your hosting account, it may be named public_html, www, htdocs, or a folder linked to the domain. Prepare the Site Before You Move Anything A WordPress move is a file and URL change, not a new installation. Your database usually stays where it is. Still, we recommend preparing a complete copy of both the files and database before touching the live site. Export the database through your hosting control panel, phpMyAdmin, or your regular backup system. Download the entire WordPress directory too, including wp-content, wp-admin, wp-includes, wp-config.php, .htaccess, and hidden files. Keep the backup somewhere outside your hosting account. If a failed move damages the live files and the only backup sits on the same account, recovery becomes much harder. Before continuing, write down these details: Record the current WordPress Address and Site Address under Settings > General. Note your database name, database user, table prefix, and hosting login. Check whether the root folder already contains another website or an index.php file. Clear or pause caching while you work, including plugin, server, and CDN cache. Schedule the move during a quiet period if the site receives orders, bookings, or contact requests. If another website already occupies the root directory, don’t move WordPress over it. Make a separate plan for that site first, or ask your host to confirm which folder belongs to your domain. How to Move WordPress Root Directory Files Once your backup is ready, open your host’s File Manager or connect through FTP. cPanel users will usually find the tool inside cPanel. Other hosts may use a custom panel with similar file controls. Open the folder where WordPress currently lives. For example, it might be public_html/blog. Then move the files inside that folder into the domain’s document root. Follow this sequence: Open the WordPress subfolder and select everything inside it. Include hidden files, especially .htaccess, if your file manager hides them by default. Choose Move, then set the destination to the root folder, such as public_html. Confirm that folders including wp-admin, wp-content, and wp-includes now sit directly inside the root. Check that index.php, wp-config.php, and .htaccess are also in the root. Leave the old folder in place until the new site works correctly. Don’t move only the wp-content folder. Don’t copy only index.php unless you’re deliberately using a different WordPress directory setup. A full move needs the complete WordPress file set. If the file manager asks whether to overwrite an existing file, stop and check what is already in the destination. Overwriting a live site’s index.php or .htaccess can take down another website. The manual WordPress subfolder migration guide also covers file transfer options through hosting tools. Update Both WordPress URL Settings After the files reach the root, open the WordPress login page at the new address, usually: https://example.com/wp-admin If WordPress redirects you back to the old subfolder, use the recovery options below before trying again. In the dashboard, go to Settings > General. You should see two fields: WordPress Address (URL) points to the location of the WordPress core files. Site Address (URL) controls the address visitors use to reach the website. For a full move to the root, remove the subfolder from both fields. Change: https://example.com/blog to: https://example.com Save the changes. WordPress may log you out and send you to the new login address. That’s expected. Both URL fields must point to the same final domain when all WordPress files have moved into the root. Changing only one field can create redirects, missing styles, or login problems. If you can’t reach the dashboard, add or edit the URL constants in wp-config.php with your hosting File Manager. Use the final root address for both WP_HOME and WP_SITEURL. If those constants already exist, edit them instead of adding duplicates. Another recovery option is phpMyAdmin. In the WordPress options table, update the home and siteurl values to the root domain. The table may have a custom prefix, so don’t assume it is named wp_options. Refresh Permalinks and Replace Old URLs Once the new root URL works, go to Settings > Permalinks and click Save Changes. You don’t need to change the permalink structure. Saving the page refreshes WordPress rewrite rules and often fixes broken page URLs. The main URL settings don’t update every old reference stored in your database. Images, menu links, buttons, plugin settings, and post content may still contain /blog. Run a search and replace for the old full URL and the new root URL. Use a WordPress migration tool or a command that understands serialized data. A basic database-wide text replacement can damage serialized settings, so don’t run a blind SQL replacement. The WordPress subdirectory installation guide provides helpful context on the relationship between directory paths and public URLs. That distinction matters when you repair old links after the move. Search for both versions of the old address: https://example.com/blog http://example.com/blog If your site recently switched to HTTPS, check for both protocols. Replace old paths in menus, widgets, theme settings, forms, and SEO plugin fields. Test the Site Before Removing the Old Folder A homepage loading correctly doesn’t prove the move is complete. Test the site as a visitor and as an administrator. Open a private browser window, then check: The homepage and several pages Blog posts, categories, and tags Images, PDFs, and downloadable files The new /wp-admin login Contact forms, checkout pages, and newsletter forms Navigation menus and footer links Search results and pagination SSL security and browser warnings XML sitemap and robots.txt Caching and mobile layouts If pages show 404 errors, save the permalink settings again. If images are missing, check their URLs in the database and media library. If the site redirects repeatedly, review the URL fields, wp-config.php, caching rules, and .htaccess. You should also create 301 redirects from the old subfolder URLs to their new root paths. For example, an old /blog/contact address may need to redirect to /contact. Test a few old URLs manually before adding a broad rule. Don’t delete the old subfolder immediately. Keep the backup and old files until you’ve confirmed that important pages, forms, and search traffic work normally. Move to Hosting That Makes WordPress Easier A directory move is also a good time to ask whether your current hosting makes routine WordPress work harder than it should. At ZADiC, our cPanel and WordPress hosting gives you familiar file tools, one-click setup, free SSL on many plans, security monitoring, and 24/7 human support. That means you can handle a move with clear access to your files, or get help when a redirect or database issue appears. If your site is growing, managed Web Hosting Plus and VPS options provide more room for traffic, plugins, and business tools. You don’t need to wait for a major outage to choose a more dependable setup. Good hosting gives you a stable place to build, update, and grow. Keep the Move Clean and Controlled To move WordPress from a subfolder to the root, back up the files and database first. Then move the complete WordPress installation into the correct document root, update both URL settings, refresh permalinks, replace old subfolder references, and test the site carefully. The most common mistakes are simple: moving only part of the installation, overwriting another site, changing one URL instead of both, or skipping the database search and replace. Take those risks out of the process, and the move becomes a controlled change instead of a stressful rebuild. A reliable host and a complete backup give you the confidence to put your WordPress site where it belongs. [...]
Read more...
WordPressHow to Repair WordPress Serialized Data SafelyWhen you need to repair WordPress serialized data, a normal database search and replace can turn one small change into a site-wide problem. Your homepage may still load, but widgets disappear, plugin settings reset, or WordPress starts throwing PHP warnings. The fix is possible. The key is to protect your database first, identify the damaged values, and use a method that understands serialized strings. We’ll walk through the safest process, then show how dependable hosting can reduce the risk next time. What WordPress Serialized Data Actually Is WordPress stores many settings as serialized PHP data. Instead of saving each setting in a separate database column, WordPress bundles related values into one structured string. A serialized array might look like this: a:2:{s:4:"name";s:5:"Alice";s:3:"role";s:5:"admin";} That string contains an array with two values. The letters and numbers tell PHP what type of data it contains and how long each value is. For example, s:5:"Alice"; means: s identifies a string. 5 tells PHP the string length. "Alice" is the stored value. That length number is the part that causes trouble during many WordPress migrations. Why ordinary search and replace breaks it Suppose a database contains this value: s:24:"https://oldsite.com"; You replace oldsite.com with newsite.com. The visible URL may still look fine, but the serialized length can change. PHP then reads the wrong number of characters and fails to decode the complete value. The damage often happens when someone runs a raw SQL query such as REPLACE() across the database. It also happens when an SQL export is opened in a text editor and edited before being imported into a new site. The database doesn’t know that the text sits inside a serialized structure. It replaces the characters and leaves the length marker untouched. PHP serialization is not limited to WordPress. This PHP serialization migration example shows how a small text change can affect the stored length and break the data around it. A serialized string counts bytes, not what the text looks like on screen. A change involving accented letters, emoji, or another multi-byte character can cause problems even when the visible length seems correct. Serialized values commonly appear in these WordPress database locations: wp_options, especially plugin, theme, and widget settings. wp_postmeta, where page builders and custom fields store configuration. wp_usermeta, which can contain user preferences and capabilities. wp_termmeta, used by themes and plugins for taxonomy settings. Custom tables created by plugins. The table prefix may not be wp_. Many hosts and security tools change it, so always check the actual prefix before writing a query or editing a table. How to Tell When Serialized Data Is Broken A broken value doesn’t always bring down the whole website. Sometimes one setting fails while everything else appears normal. That makes these problems easy to mistake for a plugin conflict or a caching issue. Look for a clear connection between the problem and a recent database change. Did the issue appear after a migration, domain change, SSL update, database import, or manual search and replace? Timing is often the first useful clue. Common symptoms include: Widgets vanish from the WordPress Customizer. A page builder loses saved layouts or global settings. Plugin settings return to their defaults. Theme options fail to load. WordPress shows unserialize(): Error at offset in the PHP error log. An admin screen displays warnings about invalid arguments. A plugin produces a fatal error after a URL or path change. The site loads only after a plugin is deactivated. A blank page can also come from a PHP version problem, a fatal plugin error, memory limits, or a damaged theme file. Don’t assume every WordPress error comes from serialization. Check the hosting error log and compare the timing with your latest database operation. Find the affected record before touching anything Start with the setting that stopped working. If a page builder lost its templates, inspect that plugin’s options and post meta. If widgets disappeared, check the relevant options instead of changing every table. Search for the old domain, file path, plugin name, or setting key. phpMyAdmin can help you inspect rows, but its search tools don’t repair serialized values. They only help you find possible locations. You may see values beginning with: a:, which usually identifies a serialized array. s:, which identifies a serialized string. O:, which identifies a serialized object. b:, i:, or d:, which identify Boolean, integer, or decimal values. Those prefixes alone don’t prove that a value is damaged. They only tell you that the field may contain PHP serialized data. Prepare a Safe Repair Before Editing the Database The database is the website’s memory. Treat it like a live electrical panel, not like a normal text document. Create a complete backup of the database and website files before making any change. Download a copy outside the server, then create another backup immediately before the repair. Name each file clearly so you know which copy is untouched. A safe repair also needs a staging copy when possible. Import the database into a separate environment, point a temporary WordPress installation at it, and test the repair there first. If the staging copy breaks, your live website remains available. Record these details before you begin: The current domain and the replacement domain. The database name and table prefix. The WordPress, PHP, theme, and plugin versions. The tables or rows connected to the problem. The date and method of the last migration. The location of your clean backup. Put the site into maintenance mode if users can submit forms, place orders, create accounts, or update content. New database writes during a repair can leave you with two different versions of the same data. Choose the repair method that matches the problem SituationSafer methodMain cautionA full site migration needs a URL changeSerialization-aware search and replaceTest with a dry run firstAn SQL dump was edited before importRepair the dump with a trusted scriptWork on a copy, never the originalOne known setting is damagedRestore the specific row or settingAvoid manual edits to long stringsImportant data is missing or truncatedRestore from a clean backupMissing bytes cannot be guessed back Don’t run a broad operation just because it feels faster. A site-wide replacement can modify plugin data, email templates, custom code, and unrelated content. How to repair WordPress serialized data safely The safest approach depends on whether the data is still valid but needs a value changed, or whether the serialized structure is already malformed. Use a serialization-aware search and replace If the data is valid and you need to change a domain, path, or URL, use a tool that reads the serialized value, updates it, and writes the correct length markers again. WP-CLI is a practical option for site owners with SSH access. On a staging copy, a command may look like this: wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables-with-prefix --precise --recurse-objects --dry-run The --dry-run option shows what would change without writing to the database. Review the table names, row counts, and replacement values before running the real operation. The --precise option tells WP-CLI to use a more careful PHP-based process. The --recurse-objects option helps it search inside nested serialized objects and arrays. The --all-tables-with-prefix option includes tables using the site’s database prefix, including many plugin tables. Once the result looks correct on staging, run the same command without --dry-run. Keep the original database backup until the site has passed every check. If you don’t have SSH access, use a trusted WordPress migration or database tool that clearly supports serialized data. Don’t choose a tool because it has a search box. Look for documentation that explains how it handles serialized arrays and objects. Repair a damaged SQL export If someone edited an SQL file in a text editor, the safest source may be the original database backup from before the edit. Restore that backup to a temporary database and perform the replacement with a serialization-aware tool. When the original database isn’t available, a repair script may be able to process the broken dump. The script needs to understand the serialized structure, update string lengths, and produce a clean import file. The Stack Overflow discussion on broken serialization covers a common migration problem involving changed table prefixes and edited SQL files. It also shows why direct text editing isn’t enough. A PHP repair script can be useful, but treat downloaded scripts carefully: Download it from a source you trust. Read the file before running it. Work on a copy of the SQL dump. Run it in a local or staging environment. Check the output before importing it. Delete the script after the repair. Never upload an unknown repair script to a live site and leave it publicly accessible. A temporary tool can become a security problem if anyone else can run it. Restore one known setting instead of rebuilding everything Sometimes the problem affects one row in wp_options or one post meta value. If you have a clean backup, restoring that specific row is safer than replacing the entire database. First, compare the damaged value with the same row in the backup. Confirm the option name, the table prefix, and the plugin or theme that owns the setting. Export the damaged row before replacing it, even if you believe it has no value. A targeted restore works well for: A lost widget configuration. A single page builder template. One plugin’s settings array. A theme customizer value. A user preference that fails to decode. Manual length changes should be the last resort. You would need to calculate the correct byte length, preserve every separator, and confirm that nested values still match. One missed character can damage the next value in the string. For that reason, we don’t recommend changing s:24: to another number by eye. Re-serializing the complete value is safer than guessing at one marker. What to Do When the Serialized Value Is Already Malformed There is a difference between changing valid serialized data and repairing data that PHP can no longer parse. A valid value can be decoded, updated, and saved again. A malformed value may contain a wrong length, a missing quote, an incomplete array, or a truncated object. Search and replace won’t fix those structural problems. The best recovery path is a clean copy of the affected row. Restore the row from a backup, then test the plugin or theme that uses it. You don’t need to restore the entire website if one option is the only damaged record. If a database value was truncated, no repair script can recreate bytes that no longer exist. Recovery then depends on a clean backup or rebuilding the setting. When no clean backup exists, make a copy of the damaged value and inspect the PHP error log. An error such as Error at offset 120 tells you where PHP stopped reading, but it doesn’t always reveal the original content. A repair script may recover a value when the error is limited to a length marker. It can’t reliably recover a value with missing content. In that situation, recreate the setting through the plugin’s admin screen, restore the page builder layout from an export, or rebuild the theme configuration manually. Also check whether the problem is actually a missing plugin class. Serialized objects can refer to PHP classes supplied by a plugin or theme. If that software is disabled, removed, or changed, WordPress may not be able to load the object even when the serialized string is correctly formatted. Install the same plugin version in a staging environment, then test the database there. If the setting loads, update the software carefully and check whether the newer version stores the data in a different format. Never pass untrusted user input directly to PHP’s unserialize() function. Serialized objects can create security risks when untrusted data is decoded. Only work with database backups and values from your own site, and use maintained tools designed for the job. The broken serialization repair guide provides another practical example of processing a damaged database dump. Use any third-party script only after reviewing it and testing it away from production. Verify the Site After Repairing the Database A successful database command doesn’t prove that the website is fixed. WordPress may still show cached settings, and the affected plugin may need to load the repaired value before you can confirm the result. Clear the WordPress cache, object cache, server cache, and CDN cache if your setup uses them. Then open the affected admin screen in a private browser window. Test the parts of the site connected to the repaired data: Load the homepage and several internal pages. Open the WordPress Customizer. Check menus, widgets, forms, and sidebars. Open page builder templates and saved layouts. Test user login and account pages. Complete a test checkout if the site sells products. Review the PHP and web server error logs. Look for the original symptom, not only a successful homepage load. A broken widget setting may not appear until a sidebar is rendered. A damaged checkout option may not appear until a customer reaches the payment page. After testing, take a fresh backup of the repaired database. Keep the pre-repair copy for a reasonable period, then remove old copies that contain sensitive customer or user data according to your backup policy. The next migration should use a staging test and a serialization-aware tool. That one change prevents many database repairs before they start. Reduce database repair risk with dependable WordPress hosting A careful repair is easier when your hosting account gives you reliable backups, useful access, and someone to contact when the site behaves strangely. Our WordPress hosting with 24/7 support includes automatic setup, automatic backups, software updates, one-click restore protection, free SSL on supported plans, and daily malware scans. Plans also include tools such as cPanel, NVMe storage, and Cloudflare CDN options, depending on the package. That doesn’t make serialized data problems impossible. It gives you a safer recovery path when a migration or plugin update goes wrong. If you’re running a small business site, you shouldn’t have to choose between editing your database alone and paying for a large technical team. ZADiC gives you practical hosting, security monitoring, backups, and human support in one place. A cPanel plan can suit a smaller site that needs simple controls and one-click WordPress setup. Managed WordPress hosting is a better fit when you want more hands-off maintenance. A VPS gives growing sites more control over server resources. The right plan is the one that matches your traffic, store activity, storage needs, and comfort with server administration. Start with dependable backups and support. Add more capacity when your website needs it. Conclusion Serialized data usually breaks because a normal text replacement changed the content without updating the length markers around it. Protect the database, test on staging, and use a tool that understands PHP serialization before changing live records. When a value is valid, re-serialize it after the replacement. When it is malformed or truncated, restore the affected row from a clean backup instead of guessing at the missing characters. With reliable WordPress hosting, automatic backups, and responsive support, one damaged setting doesn’t have to become a full website crisis. [...]
Read more...
WordPressHow to change WordPress site URL safelyA wrong URL can lock you out of WordPress, break images, and send visitors to the wrong address. That’s why you need to change WordPress site URL settings with a backup and a clear recovery plan in place. The process is usually simple when you know which address to change, where WordPress stores it, and what needs updating afterward. We’ll walk through the safest options, including the dashboard, wp-config.php, phpMyAdmin, and WP-CLI. What changes when you update a WordPress URL? WordPress uses two related addresses: WordPress Address (URL) points to the folder where WordPress core files are installed. Site Address (URL) is the public address visitors use to open your website. On most sites, both addresses are identical. They can differ when WordPress is installed in a subdirectory, such as example.com/wordpress, while the public site uses example.com. You might need to change these addresses for several reasons: Moving from a temporary domain to your real domain. Switching from http:// to https://. Changing from a non-www domain to a www domain, or the reverse. Moving WordPress from a subfolder to the main domain. Moving the site to a new hosting account. Correcting an old domain that still appears in WordPress settings. The right method depends on whether you can access the WordPress dashboard. If the dashboard works, the Settings page is the quickest option. If you’re locked out, wp-config.php, phpMyAdmin, or WP-CLI can restore access. Change you’re makingWhat must be ready firstHTTP to HTTPSA working SSL certificateTemporary domain to live domainDNS pointed to the correct hosting accountOld domain to new domainA backup, search-replace plan, and redirectsSubfolder to root domainCorrect WordPress and site addressesMove to new hostingFiles, database, DNS, and email access The WordPress migration handbook also recommends backing up your database before changing migration settings. That one step gives you a way back if the new address causes trouble. Prepare your site before changing the address A URL change can affect more than the homepage. WordPress content, image paths, theme settings, plugins, menus, forms, and third-party services may still contain the old address. Start with a complete backup of your files and database. Store at least one copy away from the server. A backup inside the same hosting account won’t help much if the account has a serious failure. Next, confirm that you can access the important parts of your hosting account: Your hosting control panel, such as cPanel. File Manager or FTP access. phpMyAdmin or another database tool. Your domain registrar and DNS settings. Your WordPress administrator account. Your SSL certificate settings. Write down the current values of both URL fields before making changes. If you’re moving between domains, record the old domain exactly, including http, https, and whether it uses www. A small difference matters during search-replace work. If you’re changing from HTTP to HTTPS, install and test the SSL certificate first. Opening https://yourdomain.com should show a secure connection before you update WordPress. If the certificate isn’t ready, WordPress may send visitors into a redirect loop or show certificate warnings. We also recommend pausing automated cache, security, and optimization changes during the update. Caching can make an old URL appear even after the database is correct. Clear the cache after the new address is working. Hosting support matters here. If backups, SSL, and database access are difficult to find, the migration becomes harder than it needs to be. ZADiC offers WordPress hosting, cPanel access, security monitoring, and 24/7 human support for site owners who want reliable infrastructure without handling every server task alone. Many plans also include free SSL, and you can review the available SSL certificate options before moving a site. How to change WordPress site URL from the dashboard Use the WordPress dashboard when the site loads normally and you can sign in. Go to Settings > General. You’ll see: WordPress Address (URL) Site Address (URL) Update both fields with the new full address. Include the protocol, such as https://, and leave off the final slash. For example, if your site is moving to a secure domain, both fields might become: https://example.com Check the spelling before saving. A missing letter, extra space, or incorrect domain can immediately make the dashboard unavailable. Click Save Changes. WordPress may log you out because the login address has changed. Open the new URL, sign in again, and visit a few pages. This method works well for changes such as: http://example.com to https://example.com example.com to www.example.com A temporary hosting URL to your live domain If you’re moving the entire site to a different domain, saving these fields is only the first step. Existing content may still contain the old URL, so you’ll need to update internal links, images, and redirects afterward. If the dashboard refuses to load, don’t keep guessing at the settings. Use one of the recovery methods below. Use wp-config.php when the dashboard is unavailable The wp-config.php method is useful when an incorrect URL has created a login loop or made the admin area unreachable. It tells WordPress which addresses to use, even when the database still contains the old values. Open your hosting File Manager or connect through FTP. Find wp-config.php in the main WordPress folder. Download a copy before editing it. Add these two lines above the comment that says That's all, stop editing! Happy publishing.: define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' ); Replace https://example.com with your real address. Use the full protocol and don’t add a trailing slash. The two constants have different jobs. WP_HOME controls the public site address. WP_SITEURL controls where WordPress is installed. For a standard installation, both values usually match. Save the file and test the homepage. Then try /wp-admin at the new address. If the site loads, the constants have taken priority over the old database values. There’s an important catch. These constants override the values in the database, which can make the URL fields in Settings > General appear locked or unavailable. That’s expected. Once the site works and you’re ready to manage the address from the dashboard again, remove both lines from wp-config.php. Keep a copy of the original file until you’ve tested the entire site. Don’t leave RELOCATE in wp-config.php as a permanent fix. WordPress documentation warns that this setting can create a security problem because an attacker may be able to influence the site URL in some configurations. This method is a strong recovery tool, but it doesn’t update old links inside posts, pages, widgets, or plugin settings. You’ll still need to complete the cleanup after restoring access. Edit the database directly with phpMyAdmin When the dashboard and configuration file aren’t enough, edit the URL values in the WordPress database. This method is precise, but it deserves more care because a wrong database edit can affect the whole site. Export the database before changing anything. In cPanel, open phpMyAdmin, select the WordPress database, and find the options table. The table is often called wp_options, but don’t assume the wp_ prefix. Many WordPress installations use a custom prefix, such as wpabc_options. Look for the table ending in _options. Find these two rows: siteurl home Edit the option_value field for both rows. Replace the old address with the complete new address, such as https://example.com. Do not change the option_name values. Do not add a trailing slash. Save each update and then test the site in a private browser window. Changing only one row can leave WordPress in a half-working state. The homepage may load while the login page fails, or the dashboard may redirect to the old domain. Update home and siteurl together unless you have a specific reason for keeping them different. A database search can also find the old URL in post content, widget settings, menus, and plugin data. Don’t run a blanket find-and-replace across every database column by hand. WordPress and plugins often store serialized data, and a basic SQL replacement can damage its structure. You can update the two main URL rows in phpMyAdmin, then use WP-CLI for a safer full-site replacement. That gives you better control over serialized values and lets you preview the changes before applying them. Avoid changing post GUID values as part of a normal domain move. They are identifiers, not ordinary visitor-facing links. Focus on content URLs, media paths, menu links, and plugin settings that still point to the old domain. Use WP-CLI for a controlled full-site update WP-CLI is a good choice when you have SSH access and want to check each step from the command line. Run commands from the WordPress installation folder. First, confirm the current values: wp option get siteurl wp option get home Update both options: wp option update siteurl 'https://example.com' wp option update home 'https://example.com' For a full domain migration, preview a search-replace operation before applying it: wp search-replace 'https://oldsite.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-run The --dry-run option shows what would change without writing to the database. Review the results carefully. If the old and new domains are correct, run the same command without --dry-run. This approach is safer than editing serialized plugin data manually. It also makes it easier to repeat the process on a staging copy before touching the live site. If you don’t have SSH or WP-CLI access, use the dashboard, wp-config.php, or phpMyAdmin instead. Your hosting provider may also be able to run the migration for you. Fix links, redirects, SSL, and caches after the change Updating home and siteurl doesn’t automatically repair every reference to the old address. Work through the site in a logical order. First, go to Settings > Permalinks and click Save Changes. You don’t need to alter the permalink structure. Saving the page refreshes WordPress rewrite rules and often fixes 404 errors after a move. Then test: The homepage and several internal pages. WordPress login and logout. Images, downloads, and embedded videos. Main navigation and footer links. Contact forms and checkout pages. Search results and category pages. Mobile layouts. Any membership or account areas. If you moved to a new domain, create permanent 301 redirects from the old URLs to the matching new URLs. Redirects help visitors and search engines find the new pages. Avoid sending every old page to the homepage when a matching destination exists. For an HTTP-to-HTTPS change, check for mixed content. A page may load over HTTPS while images, scripts, or stylesheets still request HTTP files. Update those references, then test with a browser security panel or a trusted site scanner. Clear every relevant cache: WordPress caching plugins. Server-level cache. CDN cache. Browser cache. Object cache, if your host uses one. Check your canonical URLs and XML sitemap too. They should use the new address, not the old domain or protocol. If the site uses Google Search Console, add or verify the new property and submit the current sitemap. The WordPress Codex discussion about changing the site URL also covers cases where the public address differs from the directory where WordPress is installed. That distinction matters when moving a subdirectory installation. Common problems after a WordPress URL change Most failures fall into a few familiar patterns. Knowing the symptom helps you choose the right fix instead of making more changes at random. ProblemLikely causeFirst fixLogin keeps returning to the old domainOld URL in the database or cacheAdd temporary WP_HOME and WP_SITEURL valuesToo many redirectsConflicting HTTPS or www rulesCheck SSL, proxy settings, and redirect rulesHomepage works but inner pages show 404Rewrite rules weren’t refreshedSave the Permalinks settingsImages still use the old domainOld URLs remain in post content or media settingsRun a careful search-replaceSecure page shows warningsMixed HTTP content or missing SSLUpdate asset URLs and check the certificateWhite screen after editing filesPHP syntax error or incompatible pluginRestore the backup and review the last change A redirect loop often happens when your host or CDN handles HTTPS while WordPress also receives confusing protocol information. Check the hosting SSL settings before adding more redirect rules. If you lose access after editing wp-config.php, restore the previous copy through File Manager or FTP. If the database edit caused the problem, import the backup or reverse the two changed values. When a site is business-critical, support can save hours of trial and error. ZADiC provides 24/7 human support, security monitoring, and hosting options that can grow from standard WordPress hosting to managed Web Hosting Plus or VPS services. That gives you a practical place to turn when a URL change touches DNS, SSL, server files, and databases at the same time. Final checks for SEO and visitors A successful URL change should look boring to visitors. Pages load at the new address, old links redirect properly, forms work, and no browser shows a security warning. Before you finish, check the following: The WordPress and Site Address fields show the intended URL. The old domain redirects to relevant new pages. Internal links and image URLs use the new address. Canonical tags and the sitemap use the new protocol and domain. Analytics, email forms, payment tools, and APIs use the correct address. Google Search Console has the new property or domain configuration. Cache layers have been cleared. The site works on mobile and in a private browser window. Keep the old domain registered and active when you move to a new domain. A redirect is only useful while the old address still points somewhere. Conclusion You can change WordPress site URL settings safely when you back up first, update both address values, and test the site after each major step. The dashboard is easiest, while wp-config.php, phpMyAdmin, and WP-CLI give you reliable options when access breaks. Treat the URL like part of your site’s foundation, not a small text field. With working SSL, clean redirects, updated links, and dependable hosting support, the move can be quick, controlled, and easy for visitors to follow. [...]
Read more...
WordPressProtect WordPress Application Passwords From MisuseA leaked WordPress credential can give an attacker more access than you expect. WordPress application passwords make integrations safer than sharing your main login, but they still need careful handling. These credentials can publish content, edit settings, or manage users when they belong to an account with those permissions. The fix isn’t complicated: use separate credentials, limit access, protect storage, and revoke anything you no longer trust. How WordPress application passwords work Application passwords let an external tool connect to WordPress through the REST API without receiving your normal account password. You might use one for a mobile app, publishing service, backup tool, CRM, or custom integration. WordPress generates each credential for you. Core application passwords are 24 characters long and use letters and numbers. You give the generated value to the service once, then the service uses it with your WordPress username to authenticate API requests. The credential doesn’t create a new WordPress user. It acts as the user who created it, with that user’s permissions. An application password connected to an Administrator account can therefore carry administrator-level access. That distinction matters. The password is separate from your normal login password, but it isn’t automatically limited to harmless tasks. The WordPress Application Passwords handbook recommends treating these credentials like secrets. Create one for each integration, avoid reusing them, and revoke them when they are no longer needed. The application name you enter is a label for your records. It isn’t a security control. A label such as “Backup Service” helps you identify a credential later, but it doesn’t restrict what that credential can do. Where application passwords can be misused The main risk is permission inheritance. If an integration uses an Administrator’s application password, a stolen credential may let an attacker perform almost any action available to that account. That could include changing site content, installing a plugin, creating another user, changing configuration, or accessing private information through supported API endpoints. The exact exposure depends on the account role, the REST API routes available, and your installed plugins. Several common problems make misuse more likely: One credential gets shared across several services. When the same password appears in a backup tool, content workflow, and developer script, you can’t tell which service caused a problem. A token stays active after a project ends. Application passwords don’t automatically expire. They remain valid until someone revokes them. A secret gets stored in the wrong place. Source code, screenshots, email threads, browser notes, server logs, and public repositories can all expose a credential. A user approves a malicious connection. An attacker may send a convincing link that asks a site owner to create an application password for a fake app. An integration runs over an unsafe connection. Application passwords use the HTTP Authorization header. Without HTTPS, someone who intercepts traffic may capture the credential. The account behind the password matters as much as the password itself. A strong generated token won’t protect you from an overly powerful user account or an untrusted integration. An application password is not a limited API key by default. It inherits the permissions of its WordPress user. Security also depends on your plugins and hosting setup. A compromised plugin could expose data, log requests, or create another path into the site. REST API endpoints may also attract automated probing, especially when attackers discover a valid username or leaked token. The WordPress security best practices guide from NordLayer also recommends strong account protection, secure connections, and careful control of administrative access. Those habits support application password security, too. Practical ways to protect WordPress application passwords Start with the account, not the token. Create a separate WordPress user for each service that needs API access. Give that user the lowest role that can complete the task. A publishing service may need an Author or Editor account. A backup service may need a custom role with carefully selected capabilities. Avoid using an Administrator unless the integration genuinely needs administrative actions. If WordPress core roles don’t provide enough control, a reputable role-management plugin can help you remove capabilities. Review the result after setup. A role that looks limited may still have more access than your integration requires. Next, create one application password per integration. Don’t give the same token to your developer, email platform, backup provider, and automation script. Separate credentials make investigations much easier. If one service is compromised, you can revoke its password without interrupting everything else. If a contractor leaves or a tool is replaced, you know exactly which credential to remove. Store credentials outside your code. Environment variables are a better choice than hard-coding a token in a plugin, theme, JavaScript file, or configuration committed to Git. Larger teams can use a secret manager such as GitHub Secrets, AWS Secrets Manager, or HashiCorp Vault. Keep the raw value out of support tickets and chat messages. Don’t paste it into a screenshot. If a service only accepts a token through an ordinary email message, ask how it protects stored credentials before proceeding. Use HTTPS everywhere, including staging sites that handle real data. WordPress normally requires HTTPS for application password authentication on production sites. Check your SSL certificate, redirects, and reverse proxy settings so requests don’t fall back to HTTP. A simple setup process looks like this: Create a dedicated WordPress user for the integration. Assign the lowest role that supports the required action. Open the user’s profile and create a named application password. Copy the value directly into the service’s secure credential field. Confirm the integration works, then remove temporary copies of the token. Record the integration name and owner without recording the secret itself. Protect the main WordPress account as well. Use a unique login password, turn on two-factor authentication where your setup supports it, and avoid using a predictable administrator username. Application passwords reduce the need to share your main login, but they don’t replace account security. Review, rotate, and revoke credentials Security gets easier when it becomes a routine rather than an emergency response. Keep a short inventory of every application password, its owner, its purpose, and the date it was created. Check the list during regular site maintenance. Look for old projects, duplicate integrations, unfamiliar names, and credentials that have no clear owner. Revoke anything you can’t explain. WordPress shows information such as the last-used date for application passwords. Some environments also expose the last-used IP address. Use those details as clues, not as perfect proof. A familiar service may use several IP addresses, while an unfamiliar location deserves attention. Revoke a token immediately when: A service is retired or replaced. A staff member or contractor who had access leaves. A token appears in a repository, log, ticket, or public post. You notice unexpected content changes or API activity. The integration’s account or vendor has been compromised. Rotation timing depends on your risk and workflow. A 90-day review is a reasonable starting point for active credentials. High-risk integrations, temporary projects, and credentials used by several people deserve shorter review periods. Revocation is fast, but don’t stop there after a suspected leak. Review user accounts, recent content changes, plugin activity, server logs, and hosting security alerts. Change the related account password if the WordPress user itself may have been exposed. Rate limiting can reduce automated abuse against REST API routes. A web application firewall, Cloudflare rules, or server-level controls can help restrict repeated requests to /wp-json/. Make sure those controls don’t block legitimate services before enabling strict rules. Build safer integrations on dependable hosting A secure application password still needs a secure home. Hosting should protect the WordPress files, database, connections, and logs around the integration. For small businesses and growing site owners, ZADiC makes that foundation easier to manage. WordPress hosting includes practical setup tools, SSL on many plans, security monitoring, and 24/7 human support. You can focus on your site instead of chasing server problems. When your site or integrations need more room, managed Web Hosting Plus and VPS options provide a path to scale without rebuilding everything elsewhere. That matters when a content workflow, ecommerce store, or marketing system starts sending more API requests. We recommend pairing good credential habits with hosting that keeps routine security work manageable: Keep WordPress, plugins, and themes updated. Use SSL and redirect all traffic to HTTPS. Maintain reliable backups outside the site’s public files. Review security alerts and login activity. Limit access to hosting panels and WordPress administration. The goal is simple: fewer shared secrets, fewer unnecessary permissions, and fewer places for a leaked token to cause damage. A safer WordPress API routine WordPress application passwords are useful because they separate an integration from your main login. They become risky when treated like ordinary text. Use a dedicated low-permission user. Create one credential per service. Store it in a proper secret system, keep traffic on HTTPS, and review the last-used information. Revoke access as soon as a service, person, or project no longer needs it. Hosting with security monitoring and human support can remove some of the routine pressure, but the access decisions remain yours. Make those decisions carefully, and your WordPress integrations can stay useful without becoming an open door. Conclusion A WordPress application password should be handled like a key, not a convenience string. Give each service its own key, keep it away from code and public messages, and give the account behind it only the permissions it needs. Review active credentials on a schedule, watch for unusual API activity, and revoke anything that no longer has a clear purpose. With secure hosting, HTTPS, current software, and sensible account controls, you can keep your automations moving while reducing the chance that one leaked token becomes a site-wide problem. [...]
Read more...
WordPressHow to Disable XML-RPC in WordPress SafelyA public xmlrpc.php endpoint can give attackers another way into your WordPress site. If you searched for disable XML-RPC WordPress, you’re probably looking for a practical security step that won’t break your website. The safest way to disable XML-RPC WordPress depends on how your site works. We’ll show you what XML-RPC does, when blocking it makes sense, which method to choose, and how to test the change before you walk away. What XML-RPC Does in WordPress XML-RPC is an older WordPress interface that lets external applications communicate with your website. It can support remote publishing, mobile apps, third-party integrations, and some plugin connections without requiring you to open the WordPress dashboard. That sounds useful. The problem is the same public endpoint can be abused. Attackers commonly target xmlrpc.php for two reasons: The system.multicall method can bundle many login attempts into one request. The pingback.ping method can help create reflection attacks that send unwanted traffic toward another website. A normal login page may have rate limits, CAPTCHA checks, or two-factor authentication. XML-RPC requests can sometimes avoid those protections because they use a separate pathway. Attackers may also target methods such as wp.getUsersBlogs to test stolen usernames and passwords. XML-RPC isn’t automatically a security flaw. If your site needs it, you can keep it enabled and protect it properly. If you don’t use remote publishing or related integrations, leaving the endpoint open creates risk without giving you much value. The WordPress VIP XML-RPC security controls documentation also treats disabling the endpoint as a common security measure for sites that don’t need remote access. Should You Disable XML-RPC WordPress Access? Before blocking anything, check whether your site depends on XML-RPC. A security change is only helpful when it doesn’t remove a feature your business needs. You may need XML-RPC if you: Publish posts through an older mobile app or desktop publishing tool. Use a plugin that connects to WordPress through XML-RPC. Rely on a third-party service that clearly lists XML-RPC as a requirement. Use remote publishing features that don’t work through the WordPress REST API. You probably don’t need it if you manage content through wp-admin, use current WordPress tools, and don’t have a known integration connected to the endpoint. We recommend checking your plugins before making the change. Look through plugin settings, support documentation, and your hosting security logs. If a service has been installed for years and nobody knows what it does, test the site on staging first. There’s also a middle option. Instead of blocking the entire endpoint, you can disable certain features, such as pingbacks, while keeping remote access available. That reduces some abuse without fully removing XML-RPC. It doesn’t provide the same protection as blocking xmlrpc.php, though. If your website only needs the WordPress dashboard, XML-RPC is often an unused public entrance. Closing an unused entrance is easier than defending it forever. Sucuri’s explanation of XML-RPC security risks covers the main concern: attackers can use the endpoint for brute-force activity and pingback abuse. How to Disable XML-RPC WordPress Safely We have three practical options. The best choice depends on your technical comfort, hosting setup, and whether you need a quick reversible change. Use a Security Plugin For most site owners, a reputable WordPress security plugin is the easiest route. Look for a plugin that includes a clear setting to disable XML-RPC rather than one that adds a large collection of unrelated changes. The process usually looks like this: Create a current backup of your files and database. Test the setting on a staging copy if your host provides one. Open the plugin’s firewall or hardening settings. Turn off XML-RPC access. Save the setting and test your website. A plugin-based change is easy to reverse. That matters if Jetpack, a mobile app, or another integration stops working after the update. Choose a maintained plugin from a trusted developer. Check its recent updates, WordPress compatibility, support activity, and user reviews. Avoid installing several security plugins that all modify the same endpoint. They can conflict and make troubleshooting harder. This approach may block XML-RPC through WordPress or add a server rule, depending on the plugin. Read the setting description before you enable it. Some plugins only disable authenticated XML-RPC methods, while others block the endpoint completely. Add a WordPress Filter Developers can disable authenticated XML-RPC methods with a small WordPress filter. Add the following code to a custom functionality plugin or a must-use plugin: add_filter( 'xmlrpc_enabled', '__return_false' ); Don’t place this in a theme’s functions.php file unless you understand the tradeoff. The code disappears when you change or replace the theme. A small custom plugin is a better long-term home. There’s an important limitation here. The xmlrpc_enabled filter disables methods that require authentication, but it may not block every XML-RPC request. Pingbacks and other unauthenticated behavior may still need separate controls. That means this method is useful, but it isn’t always a complete block. If your goal is to stop all public requests to xmlrpc.php, use a web server or firewall rule instead. Block the Endpoint at the Server or Firewall A server-level block stops requests before WordPress has to process them. That can reduce wasted server work and block unwanted traffic earlier. On Apache hosting, a qualified administrator can add an access rule for xmlrpc.php. On Nginx, the equivalent is usually a location rule that denies access to that exact file. The syntax depends on your server version and configuration, so don’t paste random rules into .htaccess. You can also create a firewall rule through a provider such as Cloudflare. A rule that blocks requests to the path /xmlrpc.php can prevent the traffic from reaching your hosting account. This is often the strongest option for a site that has no XML-RPC dependency. It also avoids relying on a WordPress plugin to load before the unwanted request is rejected. If your site uses cPanel hosting, ask your hosting provider for help before editing server files. A bad .htaccess rule can produce a 500 error or block more than intended. With managed hosting, support can check the configuration, apply the rule safely, and help restore access if an integration breaks. Providers such as ZADiC focus on managed WordPress and hosting support for site owners who don’t want every security task to become a server project. Hosting with SSL, monitoring, backups, and human support gives you a safer place to make changes like this. How to Check That XML-RPC Is Disabled Don’t assume the change worked because the plugin says it did. Test the actual endpoint. Open https://yourdomain.com/xmlrpc.php in a browser, replacing yourdomain.com with your domain. An enabled endpoint often responds with a message that says the XML-RPC server accepts POST requests only. A blocked endpoint may return a 403 or 404 response, depending on the rule. You can also ask your hosting provider to check the access logs. Look for recent requests to /xmlrpc.php and confirm that the server is denying them. Then test the parts of your website that matter: Log in to the WordPress dashboard. Publish and update a post. Submit a contact form. Check connected plugins and marketing tools. Confirm that scheduled tasks and backups still run. Test any mobile or remote publishing app you use. A security scanner can provide another check. Wallarm’s guide to XML-RPC attack protection explains how exposed XML-RPC endpoints can be identified and protected. If your site still responds to XML-RPC after a WordPress filter is added, that doesn’t necessarily mean the code failed. It may only have disabled authenticated methods. Use a server or firewall block when you need the endpoint closed completely. What to Do If Your Site Needs XML-RPC Some websites need XML-RPC for a specific integration. In that case, don’t disable it without checking what will stop working. Start by updating WordPress, plugins, themes, and your PHP version. Use HTTPS across the site so credentials and other traffic are encrypted in transit. Turn off pingbacks if you don’t need them, and restrict access to known services when your firewall supports allowlists. Strong account security still matters. Use unique passwords, administrator two-factor authentication, limited user permissions, regular backups, and login monitoring. XML-RPC protection should support those measures, not replace them. Review your logs after enabling XML-RPC. A sudden increase in requests to xmlrpc.php, repeated login failures, or unusual pingback activity deserves attention. Invicti’s overview of IP disclosure attacks provides more context on how XML-RPC can expose information during certain attacks. Final Thoughts For a WordPress site that doesn’t use remote publishing, disabling xmlrpc.php is a sensible security improvement. A plugin is convenient, a WordPress filter is flexible, and a server or firewall block offers the clearest full shutdown. Back up first, test the change, and confirm that your important integrations still work. The right hosting setup can make that process easier, with security monitoring, SSL, backups, and support available when a technical setting needs more than a quick click. A small unused endpoint shouldn’t create a large security headache. Close it when you don’t need it, protect it carefully when you do, and keep your website ready for growth. [...]
Read more...
WordPressHow to Create a WordPress Child Theme Without Losing CustomizationsA theme update shouldn’t erase hours of design work, custom CSS, or carefully added functions. Yet that can happen when changes are made directly to a parent theme. A WordPress child theme gives you a safer place to customize your site while keeping the original theme available for updates. We use child themes for targeted changes, such as styling adjustments, custom functions, and modified templates. With the right setup, you can update the parent theme without starting over. Let’s begin with what a child theme protects and what it doesn’t. Key Takeaways A child theme stores your custom code separately from the parent theme. The child theme needs a style.css file and a functions.php file. The Template value must match the parent theme’s folder name exactly. Existing Customizer settings, template edits, and custom code may need to be moved manually. Backups, staging, and dependable WordPress hosting make theme updates safer. Why a WordPress Child Theme Protects Your Changes A parent theme is the main theme installed on your WordPress website. It contains the templates, styles, functions, images, and other files that control the site’s appearance and behavior. A child theme depends on that parent theme. It can use the parent’s files while allowing you to add or override selected files in a separate folder. WordPress loads the child theme’s version when both themes contain the same template file. Think of the parent theme as the original house plans. The child theme is your approved renovation file. You can repaint a room, change the layout of one area, or add new fixtures without writing over the architect’s original plans. The biggest reason to create one is simple: parent theme updates can overwrite direct edits. If you edit the parent theme’s style.css, functions.php, or single.php, those changes may disappear when the theme developer releases a new version. The WordPress Theme Handbook provides a useful explanation of how child themes work, including the files required and the way WordPress handles template overrides. A child theme protects code changes by keeping them outside the parent theme’s update path. That protection has limits. A child theme won’t automatically preserve every setting made through the WordPress Customizer. It also won’t fix custom code that depends on a function the parent developer removes. The goal is not to make updates risk-free. The goal is to keep your work separate, organized, and easier to test. Prepare Before Creating the Child Theme Creating the files is quick. Moving existing customizations safely takes more care. Before you begin, find out what has already been changed on the website. Make an inventory of current changes Look through the parent theme folder and record anything that differs from the original theme. Common locations include: style.css for custom styles functions.php for PHP snippets and theme functions Template files such as header.php, footer.php, page.php, and single.php JavaScript files that were added or edited Images, fonts, and other assets placed inside the theme folder Don’t assume every change was made in the theme files. Custom CSS may be stored under Appearance > Customize > Additional CSS. Page builders may store layouts in the database. Plugins may contain snippets that affect the site’s design. If you use an FTP client such as FileZilla, download a copy of the current theme folder before making changes. You can also compare your files with a fresh copy of the same parent theme version. That comparison helps separate your work from the original files. Create a complete backup Make a backup of both the WordPress files and the database. The database contains posts, pages, Customizer settings, menus, widgets, and many theme options. A copy of the theme folder alone isn’t enough. Keep the backup somewhere separate from the hosting account. If a failed update affects your account, a second backup location gives you another way back in. A plugin such as UpdraftPlus can handle scheduled backups, although your hosting provider may also include backup tools. Check how often backups run, where they are stored, and whether you can restore them before relying on them. Use staging when available A staging site is a private copy of your website where you can test the child theme and parent theme updates. It lets you find layout problems before visitors see them. Test the main actions on your website, not only the homepage. Check contact forms, shopping cart pages, login screens, blog posts, mobile layouts, and any page built with a visual editor. If your current hosting plan doesn’t provide staging, you can still create a backup and work during a low-traffic period. However, staging is the safer option for a business website. Reliable hosting, regular backups, security monitoring, and human support reduce the technical pressure around changes like this. ZADiC’s WordPress hosting and managed Web Hosting Plus options are built for site owners who want the infrastructure handled without giving up room to grow. Create the Two Core Child Theme Files A child theme normally needs two files: style.css functions.php Both files belong in a new folder inside wp-content/themes/. The folder name can be different from the parent theme, but use lowercase letters and hyphens to keep it clear. For example, if the parent theme folder is astra, you could name the child folder astra-child: wp-content/themes/astra-child/ The folder name is not the same thing as the theme name shown in the WordPress dashboard. The folder name is used by WordPress internally, so keep it simple and avoid spaces. Add the child theme stylesheet Create a file named style.css inside the child theme folder. Add a theme header like this: /* Theme Name: Astra Child Template: astra Version: 1.0.0 */ The required value is Template. It must match the parent theme’s directory name exactly, including capitalization where applicable. If the parent theme is stored in a folder called generatepress, the header needs to use: Template: generatepress It must not use the display name, a download filename, or the theme’s website name. A wrong Template value prevents WordPress from identifying the parent theme correctly. You can add your own CSS below the header. For example: body { background-color: #f7f7f7; } Keep the stylesheet focused on your changes. Don’t copy the entire parent style.css into the child theme. Duplicate files create more work during updates and make troubleshooting harder. Load the parent stylesheet correctly The child theme needs access to the parent theme’s styles. Modern WordPress practice is to load the parent stylesheet through functions.php, rather than using @import in style.css. Create functions.php in the child theme folder and add: <?php function zadic_child_enqueue_styles() { wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' ); } add_action('wp_enqueue_scripts', 'zadic_child_enqueue_styles'); The child theme’s functions.php is loaded alongside the parent’s file. It doesn’t replace the parent file. That means you should add your custom functions to the child file, not copy the parent’s functions into it. Some themes use several stylesheets or a special method for loading styles. Always check the parent theme’s documentation if the basic approach doesn’t produce the expected result. The child theme appears in the WordPress dashboard after its folder and stylesheet header are valid. Install and Activate the Child Theme Once the files are ready, upload the child theme folder to wp-content/themes/. You can use your hosting control panel’s file manager, SFTP, or FTP. You can also compress the folder into a ZIP file. The ZIP should contain the child theme folder, with style.css and functions.php directly inside it. Avoid creating an extra folder level such as astra-child/astra-child/style.css. In the WordPress dashboard, open Appearance > Themes. The child theme should appear beside the parent theme. Select Activate on the child theme. The parent theme must be installed, but it doesn’t need to be active. WordPress uses the active child theme and its associated parent theme together. After activation, view the site in a private browser window. Check the header, navigation, fonts, spacing, footer, blog posts, and responsive layout. Clear your caching plugin and browser cache if changes don’t appear immediately. If the website shows a blank page or a PHP error, don’t keep refreshing the live site. Use your hosting file manager or SFTP to rename the child theme folder temporarily. WordPress will usually fall back to another installed theme, allowing you to correct the error. A missing semicolon, an incorrectly named function, or a bad file path can break a PHP file. Make one change at a time, and keep a clean copy of the last working version. Move Existing Customizations Into the Child Theme Creating a blank child theme won’t bring old customizations with it. You need to move each type of change to the right location. Transfer custom CSS Copy CSS rules from the parent theme’s style.css into the child theme’s stylesheet. Move only rules you wrote or changed. Leave the parent theme’s original CSS in the parent theme. If your CSS was added under Additional CSS, you can usually leave it there. Those settings are stored in the database rather than inside the parent theme files. Still, export or document them before changing themes. Some Customizer settings are tied to the active theme. Colors, typography choices, header settings, widget placements, and layout options may not transfer from a parent theme to its child automatically. Review every setting after activation. If the site has many Customizer changes, use a reputable Customizer export and import tool. Export the settings from the parent theme, activate the child theme, and import them if the tool supports that theme structure. Always test the result first. Move functions and PHP snippets Copy your custom PHP functions into the child theme’s functions.php. Do not copy the full parent file. The parent functions are already loaded. Give custom functions unique names. A generic name such as custom_setup() could conflict with a function from the parent theme or a plugin. Prefixing the function helps, such as zadic_custom_setup(). Check every snippet before adding it. Some snippets depend on a theme function, template, or plugin that may have changed. Add one snippet at a time and test the site after each change. For scripts, styles, and custom assets, use WordPress enqueue functions instead of hardcoding files into the header. If you need to replace a parent script, the process may involve wp_dequeue_script() followed by wp_enqueue_script() for your child version. Copy only the templates you need WordPress checks the child theme first for template files. If it finds single.php in the child theme, it uses that file instead of the parent version. To customize a template, copy the original file from the parent theme into the matching location in the child theme. Then edit the child copy. For a small change to blog posts, your structure may look like this: astra-child/ style.css functions.php single.php If you need a template inside a subfolder, preserve that folder structure. For example, a WooCommerce template override belongs in the appropriate WooCommerce path, not randomly in the child theme’s root folder. Copying every parent template defeats the purpose of a child theme. It creates a large set of files that you must compare and maintain. Override only the files you actually need. Before copying a template, check whether a hook or filter can achieve the same result. Hooks usually survive parent theme updates better than a full template copy because they keep your change separate from the theme’s layout code. The WordPress child theme handbook also recommends using the child theme for modifications while allowing the parent theme to provide the rest of the site’s structure. Check Your Theme Customizations After Activation Activation is not the finish line. It’s the first proper test. Open the site on a desktop browser and a mobile device. Compare important pages with screenshots or your backup site. Look for changes in: Header height and navigation spacing Font sizes, colors, and line breaks Featured images and blog post layouts Buttons, forms, and call-to-action sections Sidebars, widgets, and footer columns WooCommerce product, cart, and checkout pages Page builder templates and reusable blocks Use your browser’s developer tools to inspect a problem element. A parent stylesheet may load after the child stylesheet, which can make your rule appear ineffective. In that case, check the CSS loading order and selector specificity before adding !important. Review the page source and browser console for missing files or JavaScript errors. A child theme can be active while still pointing to the wrong asset path. Check the WordPress Site Health screen too. PHP warnings and plugin conflicts may not show on the homepage. If you run a business site, test the lead form and email notifications before declaring the migration complete. You can follow a visual walkthrough with this child theme setup tutorial if you prefer to see the folder and dashboard steps on screen. Update the Parent Theme Without Losing Work Once your customizations live in the child theme, you can update the parent theme without overwriting those child files. That doesn’t mean you should update without testing. Parent themes can change their markup, CSS class names, hooks, function names, or template structure. Your child theme may still load, but a copied template could become outdated. Use this update routine: Back up the live website and database. Read the parent theme’s changelog. Update the parent theme on staging first. Test the pages and functions you customized. Compare the changed parent templates with your child copies. Fix compatibility issues on staging. Push the tested changes to the live site. Test the live site again. A copied single.php file is the most common source of hidden maintenance work. If the parent developer adds a new accessibility attribute or changes a template function, your older child copy won’t receive it automatically. Keep a record of every file you override and every snippet you add. A short document with the file name, purpose, and date can save hours later. Version control is useful for sites with frequent changes. Git lets you compare revisions, identify the change that caused a problem, and restore an earlier version. If you don’t use Git, keep dated ZIP backups of the child theme. A safe update process gives you time to test changes before customers encounter them. A child theme protects your files, but it doesn’t protect an outdated override from future parent-theme changes. Review copied templates after every major update. Common Child Theme Problems and Fixes The child theme doesn’t appear Check the folder location and stylesheet header. The folder must be inside wp-content/themes/, and style.css must contain a valid Theme Name value. The parent styles are missing Confirm that Template matches the parent folder name. Then check the enqueue function in functions.php. Clear caching after correcting the file. Changes in style.css don’t show Your CSS may be cached, loaded before the parent stylesheet, or overridden by a more specific selector. Clear caches and inspect the element in your browser. The website shows a PHP error Look at the latest change in functions.php. A syntax error often comes from a missing semicolon, bracket, or quotation mark. Remove the newest snippet through SFTP or your hosting file manager, then test again. Customizer settings disappeared Some theme settings belong to the parent theme’s database entry. They may need to be exported from the parent and imported into the child. Review Customizer settings manually if the export tool doesn’t support your theme. A template override stops working Compare the child copy with the latest parent version. Look for changed function names, hooks, HTML structure, and template parts. If the change is no longer needed, remove the override and let the child theme inherit the updated parent file. When a Child Theme Isn’t the Best Choice A child theme is a strong fit for focused changes. It may not be the right tool for a complete redesign. If you replace most of the parent theme’s templates, create a different content structure, and maintain large amounts of custom code, a custom theme may be easier to manage. A large child theme can become a second theme with an older parent underneath it. Block themes also need a slightly different approach. Site Editor changes saved to templates can remain in the database, while copied templates and template parts in a child theme give you file-based control. A theme.json file can manage styles and settings in a block-based child theme. Choose the simplest setup that matches the work: Project needPractical optionSmall CSS adjustmentsAdditional CSS or a child stylesheetCustom PHP snippetsChild theme functions.php or a site-specific pluginOne changed templateCopy that template into the child themeSeveral major layout changesA custom theme or carefully planned child themeBlock theme style changesSite Editor settings or child theme theme.jsonFeatures needed after a theme changeA plugin instead of theme code Theme styling belongs in a child theme. Features that should remain when you switch themes usually belong in a plugin. For example, custom post types, business logic, and important shortcodes shouldn’t disappear because you changed the site’s design. Give Your WordPress Site a Safer Foundation Theme files are only one part of a dependable website. Your hosting affects how easy it is to back up, test, secure, and recover your site. For a small business or growing project, look for WordPress hosting with one-click setup, SSL, security monitoring, reliable backups, and support from people who can help when something goes wrong. Shared hosting can work for smaller sites, while managed hosting or a VPS gives you more room as traffic and site complexity increase. ZADiC provides cPanel and WordPress hosting, managed Web Hosting Plus, VPS options, domain registration, professional email, SSL certificates, and website security tools. The goal is straightforward: give you reliable infrastructure without forcing you to become a server administrator. That matters when a theme update goes sideways. You need a clear backup process, a place to manage files, and support that doesn’t leave you searching through vague help articles. A good hosting setup lets you focus on your pages, customers, and sales while the technical foundation stays dependable. Conclusion A child theme keeps your custom CSS, PHP, and template changes separate from the parent theme. Build the folder correctly, match the Template value exactly, enqueue the parent stylesheet, and move existing changes carefully. Back up the site before you begin. Test updates on staging when possible, review copied templates, and keep notes about every customization. With a WordPress child theme and dependable hosting behind it, updates become a controlled maintenance task instead of a reason to rebuild your website. [...]
Read more...
WordPressWordPress Multisite Vs Separate Sites for Small BusinessesRunning several business websites can feel like choosing between one big filing cabinet and several smaller ones. Both can work. The right choice depends on how closely your sites are related, who manages them, and how much independence each business needs. When comparing WordPress multisite vs separate sites, the short answer is clear: Multisite is convenient for closely connected websites, while separate installations offer more control and fewer shared risks. We’ll help you weigh both options before you invest time, hosting resources, and money. Key Takeaways WordPress Multisite manages several websites from one WordPress installation. Separate sites offer stronger independence for branding, plugins, security, and access. Multisite fits connected brands, regional sites, franchises, and internal networks. Separate installations are usually safer for unrelated businesses or client websites. Good hosting, backups, security monitoring, and support matter whichever setup you choose. How WordPress Multisite Works WordPress Multisite lets you create multiple websites inside one WordPress network. Each site can have its own domain or subdomain, content, users, and settings. A Super Admin manages the network from one central dashboard. Think of it as an office building. Each business has its own room, but the building shares power, plumbing, security, and maintenance. That shared structure saves time, but a problem with the building can affect every room. A Multisite network uses one WordPress core installation. Themes and plugins are installed at the network level, although administrators can control which sites use them. Updates can happen from one place, and users may access more than one site with the same account. This setup works well when the websites share: A brand identity Similar layouts and features One technical team The same hosting account Central billing and administration A common content or marketing strategy For example, a company could run its main site, regional websites, careers site, and resource hub on one network. A school district could manage separate school websites under one system. A franchise organization could give each location its own site while keeping central control over themes and approved plugins. The structure is efficient, but it isn’t magic. WordPress Multisite still needs careful user permissions, regular backups, plugin testing, and reliable hosting. If every site is different, the shared setup can create more work instead of less. WordPress Multisite vs Separate Sites: The Main Differences Separate sites use independent WordPress installations. Each website has its own files, database, administrator accounts, themes, plugins, updates, and backup schedule. That separation gives every site a private workspace. If one website needs a special plugin, a different theme, or a custom checkout process, it can have those features without changing the others. Here’s how the two approaches compare: AreaWordPress MultisiteSeparate WordPress sitesAdministrationOne central dashboardEach site has its own dashboardUpdatesShared WordPress core, themes, and pluginsUpdates handled independentlyBrandingEasy to keep consistentEasier to customize fullyPlugin choicesCan be restricted across the networkEach site can use different pluginsSecurity impactA problem may affect the networkIssues are usually isolatedUser managementShared users can access several sitesUsers are managed per siteMigrationMore complexUsually simplerScalingEfficient for connected sitesFlexible for unrelated or growing sites The biggest difference is shared responsibility versus independent control. Multisite reduces repetitive administration. Separate installations reduce the chance that one site’s needs or problems affect another. A practical comparison from ManageWP also highlights this tradeoff between central management and independent customization in its WordPress Multisite comparison. When Multisite Makes Sense Multisite is a strong choice when your websites are part of one organized network. A regional business is a good example. Imagine a company with locations in Texas, Florida, and Georgia. Each location needs local contact details, opening hours, staff information, and service pages. The central team may still want one brand style, one approved plugin set, and one update process. Multisite can also suit: Universities with separate department websites Nonprofits with chapters in different cities Franchises with location-based websites Publishers managing several related publications Companies operating several regional domains Membership organizations with local branches The management savings can add up. You may not need to log into five dashboards to update a header, install a security tool, or review user access. One network can provide a consistent foundation. Multisite is also useful when the same people manage every website. A small marketing team can publish content across several sites without switching between unrelated systems. There’s another advantage: shared resources can simplify branding. Fonts, approved themes, forms, analytics tools, and SEO settings can stay consistent across the network. That helps visitors recognize the company wherever they land. Still, keep the relationship between sites genuine. If the websites only share an owner but have different customers, designs, plugins, and administrators, Multisite may become restrictive. When Separate Sites Are the Better Choice Separate installations usually make more sense when each website is its own business, brand, or technical project. Suppose you own a restaurant, a consulting company, and an online store. These sites may need different payment tools, user roles, themes, performance settings, and privacy controls. Putting them into one network could create unnecessary connections between unrelated operations. Independent sites are often better when: Each brand needs a different design Different people manage each website Sites use different plugins or themes One site handles payments or customer accounts You may sell or transfer a site later The websites need separate hosting environments A security issue must stay contained Separate sites also make troubleshooting easier. If a plugin update breaks the restaurant website, the consulting site keeps running. You can test changes on one installation without worrying about the rest of the network. This independence has a cost. You’ll manage more dashboards, updates, backups, and hosting settings. A reliable provider can reduce that workload with one-click WordPress setup, automatic tools, SSL, security monitoring, and human support. For small businesses, managed Web Hosting Plus can provide room for several independent sites without forcing them into one Multisite network. You can review ZADiC Web Hosting Plus when you need stronger hosting resources and a simpler management experience. Security, Backups, and Plugin Risk Security is where the WordPress Multisite decision deserves extra care. In a separate-site setup, each installation has its own files and database. A compromised plugin or weak administrator password may still cause serious damage, but the issue is less likely to spread automatically to every site. Multisite shares important infrastructure. A vulnerable plugin, compromised Super Admin account, or server-level issue can put the whole network at risk. User permissions need careful attention because a Super Admin has far more control than a regular site administrator. Plugin compatibility matters, too. A plugin that works perfectly on one site may conflict with another site’s theme, forms, checkout system, or content structure. Multisite can limit your choices when sites need different tools. The WordPress Multisite security guidance from MultilingualPress covers a key concern: shared plugins and themes can create wider security exposure when sites are not properly separated. Whatever structure you choose, use: Strong administrator passwords and two-factor authentication Regular off-site backups Security monitoring Updated WordPress core, plugins, and themes Limited administrator access A tested recovery plan Backups are especially important before network-wide updates. A single update can affect every site in a Multisite installation, so restoring one site may not be as simple as restoring one independent installation. Hosting and Growth Considerations Your hosting plan needs to match the way your network grows. Multisite can save resources because several sites share one WordPress installation. That doesn’t mean every site is free to operate. Each site still uses storage, database capacity, memory, bandwidth, and server processing. Traffic spikes can affect the network. A popular campaign on one site may use resources needed by the others. If one website grows into a busy store, membership platform, or media site, the shared setup may become a bottleneck. Separate sites give you more flexibility. You can move a busy site to a stronger plan without changing the smaller sites. You can also place sensitive or high-traffic websites on different servers. For growing networks, ZADiC VPS hosting offers a path toward more dedicated resources and control. A VPS can be useful when traffic, applications, or performance needs have moved beyond basic shared hosting. Before choosing, ask: How many websites do you expect within the next two years? Will one site receive far more traffic than the others? Do all sites need the same plugins and PHP settings? Could you sell or separate one site later? Who needs administrator access? How quickly must each site recover after an outage? These questions reveal whether shared convenience or independent flexibility matters more. A Practical Decision for Small Business Networks Choose WordPress Multisite when the sites are tightly connected and one team controls the network. Shared branding, similar features, and central administration are strong signs that Multisite will fit. Choose separate sites when the websites serve different audiences or have different owners, designs, plugins, or risk levels. The additional administration is often a fair price for independence. Our advice is simple: don’t choose Multisite only because you want fewer logins. Choose it because the websites belong together operationally. If they don’t, separate installations will likely save frustration later. A good hosting provider can support either path. Look for one-click WordPress installation, free SSL where included, dependable backups, security monitoring, scalable plans, and 24/7 human support. Those details matter more than squeezing every site into one dashboard. Final Thoughts The right answer in the WordPress multisite vs separate sites decision comes down to connection and control. Related websites with shared management often benefit from Multisite. Independent brands and high-risk projects usually need separate installations. A small business network should make daily work easier, not tie every website to the same set of limitations. Choose the structure that protects your sites, supports your team, and gives each business room to grow. That foundation lets you focus on customers instead of fixing hosting problems. [...]
Read more...