I have a plone website on which I want to set up a Varnish cache. The caching part is working great, but I have problems on the purging part.
On my setup, the "view" URL and the "edit" URL are on two different names (eg. myexample.com and plone.example.com/MyExample/) and this Plone is on a multisite environment.
Up to this point, when I save a page on the "edit server", it sends a purge request, but on the "edit" URL. (eg. on /MyExample/my/path instead of /my/path).
Question is : what's the easiest / best way to rewrite the purge URL to remove the leading /MyExample part ?
I am new to Plone and to Varnish, so any help is appreciated.
Since some purge urls are being generated, I assume that you are already using the caching tools shipped with Plone.
It could be that altering those purge paths in required way, would require to write an additional purge add-on for Plone caching tool.
Instead you may want to try an add-on called collective.purgebyid (requires some additional Varnish config). It adds an additional purge strategy based on involved unique content ids instead of paths.
Related
We have created a duplicate of our website on a new server as part of a migration. We have a wordpress blog that is part of our website.
The docroot of the wordpress site is set as an alias in our main site. The result is that to access the site home page, the following url is used: https://www.rephunter.net/blog/.
The new environment is not available to the public at this time, and is only accessible within our VPN. When the above link to the blog is followed, instead of the expected home page of our blog, we get the page at https://www.rephunter.net/blog/wp-admin/install.php, which wants to install a new site.
The configuration in the new environment is supposedly an exact copy of our production site from some time back. The permissions on the main files is the same.
What is it that is causing the attempted blog access to be redirected to the installation script?
EDIT:
The responses so far have not really absorbed the intent of the previous information. We are not migrating in the normal sense. Rather we are testing in a new virtual environment that will eventually lead to a more normal migration.
We have an exact duplicate of our original wordpress and database environment that is running in a virtual environment with an updated protocol stack that is only accessible if you are on the VPN for that environment. As far as we can tell, there is no difference in the configuration.
For example, the parameters in wp-config.php are exactly the same as in the original installation. When php runs, it sees the same environment, with host names and everything identical. It would not work otherwise.
Yet if there really were no difference, it would just run. But since WP is trying to install a new database, there is something different that we are missing.
To further illustrate this: supposed you took an image backup of the wordpress installation and the database, and put it in a different VM, and set up the DNS and everything as it needs to be--the new environment looks no different than the old one. All databases, wp-config settings, etc, are the same. So our main website and database functions very similarly.
As I mentioned above, the difference in the protocol stack should be considered. The old system is on PHP 5.6.27--the new one is on 7.3.4. So that could be causing some difference, which maybe somebody might recognize. Wordpress is 5.2.2 and should be compatible with both PHP levels.
We believe there is some relatively simple parameter setting that we are missing. For example, as in the first answer that $table_prefix is set wrongly. But that is not it in this case.
WordPress redirects you to that installation screen because the database it's connecting to is working (meaning, the username and password are correct), but the data it's expecting to be there isn't. Therefore, it assumes it's a new / empty database and prompts you to install WordPress.
I've seen this happen in two scenarios:
The database really is empty, and thus WP needs to install the standard tables and info
The table prefix in your wp-config.php file is incorrect for an existing database
Look at your wp-config.php file in the root directory of WordPress, and look for a line similar to this:
$table_prefix = 'wp_';
Then, open up the database (phpMyAdmin or some other interface to browse what the database structure actually is) and confirm that the table prefixes (the first few characters of the table names) actually match what's set above.
Hopefully this gives you something to go on! Let us know what you find
Migrating Wordpress websites can be quite tricky. I've worked as a WP developer for a number of years and always struggled with manually migrating websites.
There are a number of factors to consider:
WP stores a lot of installation specific information within the database. So you can't do a database dump and upload the export into a new database.
Changing the website url within the wp_options table in the databased there are still other references to the original url scattered throughout the db.
You could try a find and replace all using an editor that supports this sort of functionality (vscode, sublime, atom) but things always end up breaking and your doing tons of "find & replace" actions.
I have always relied on a 3rd party tool Backup Buddy as it simplifies the entire backup and migration process and offers the peace of mind of having easily deployable backups for your website.
Backup Buddy allows you to export your website as a zip and then you can move the zip to any server you want and the plugin provides an installer script (php) to guide you through the migration of your wp site to any host and database of your choosing.
Note: I am not in any way affiliated with iThemes or Backup buddy, and I do not stand to benefit in anyway if you decide to use the plugin. This is only advice on a tool that I have found helpful, reliable, have had success with, and currently actively use on a number of websites that I maintain.
WordPress display installation page because you have not update your wp-config.php file after migrating server so please follow below steps in future when you migrate your website.
Please follow this steps when you migrate your WordPress website from one server to another server.
Back up your website files/database
Export wordpress database.
Create database on your new host server.
Edit the wp-config.php File and edit this details.
Add new database name
Add new database username
Add new database user Password
Add new host as per your hosting provider or (localhost is default)
Import your database to new server.
upload the WordPress files to your new host
defining new domain URL & Search/Replace old domain URL
I recently activated a domain for my website:
http://website.webfactional.com —> http://website.com
The problem is all the internal urls (ex: website.webfactional.com/index.php?cID=277) have not been rewritten with the new address. How can I do this without manually editing each entry?
Have you tried clearing the cache?
FYI - It's best to disable all caching before moving a site and setting it appropriately after the move.
Also, if you are running v7+ make sure your canonical URLs have your new website (not the old one - which should not be set during development).
You should also Enable Pretty URLs in the dashboard (and in .htaccess if you are running under an Apache server).
See URLs and Redirection
I want to dispaly post of non ssl wordpress site to my ssl site but while displaying images it gives mix content warning in console.
How to solve it pls help.
Solution 1 :
This is the simplest fix. If an asset (image, script, etc.) is hard-coded into a plugin or theme, change it from http://example.com/assets/logo.png to https://example.com/assets/logo.png.
Typically, this is most useful when including assets from other servers, like Google scripts, API scripts, or iframes.
Before doing this, however, you need to make sure the HTTPS version is available. If loading an asset from a site that doesn't have HTTPS enabled, it's probably best to remove the reference entirely (i.e. comment out or delete) or to save the asset to your own server and change the source to load via your site instead.
Solution 2:
References to your images are stored in your database, both in the wp_posts and wp_postmeta tables (in a standard install. You might have given your tables a prefix, but locating them should in any case be doable).
Since you mentioned using phpMyAdmin I guessed you are able editing the contents of your database with this tool.
Via phpMyAdmin you could manually locate and change the urls pointing to your images (removing the 'wp' part). But as this might be quite a few database entries, replacing all in one go is a more convenient decision.
I myself have had satisfactory results by
exporting the complete database as a .sql file through the phpMyAdmin export option.
editing this file with a text editor (converting the incorrect urls to the correct ones, make a backup copy first in case anything goes wrong, never forget the backup!)
deleting all database tables (for the wp install you're trying to correct)
importing the edited .sql file
I have a multisite Wordpress (3.0.5, but the problem persists since 3.0.0) install, in which I can see that the domain URL (from: Super admin/sites/Domain) is beginning with https, what I definitely do not like, as having a self-made cert, users always get an annoying error message from the browser.
I would like to set it to begin with a simple http but have no idea how to do that. I have looked though (I think) all options in the admin panel, I have checked the MySQL database also (xxx_blogs, xxx_sites, xxx_blognumber_options -- in which xxx stands for my secret db prefix), but have no idea how to change that.
If I look into the Domains menu in Superadmin, I cannot even see my main domain, only others.
If anyone would have an idea to solve the issue, I would be very happy, as my page is quite useless sometimes (as loading e.g. images from files dir is just not working without accepting the security risk of using an untrusted cert).
Unfortunately buying a cert is not an option (thank to limited number of private IPs).
Update: I really do not find any options to set my domain name without https.
Though I have the followings in my site options:
Wordpress-https Internalurls
Wordpress-https Externalurls = 0
Wordpress-https Bypass = 0
Wordpress-https Disable Autohttps = 0
Wordpress-https Exclusive Https = 0
Wordpress-https Frontpage = 0
Wordpress-https Sharedssl = 0
Wordpress-https Sharedssl Host
You're technically doing a site move here. You're going to need to update the site settings for all hosted sites in the database and posts, unfortunately.
According to the codex:
"The best way to move Multisite is to move the files, edit the .htaccess (if the folder name containing Multisite changed), and then manually edit the database. Search for all instances of your domain name, and change them as needed. This step cannot yet be easily automated. If you're moving Multisite from one folder to another, you will need to make sure you edit the wp_blogs entries to change the folder name correctly."
In order to do the changes, you'd be much better off writing a program to return the matching entries from each field, replacing with a regex, and updating the row than trying to do it manually. Off the top of my head, I'd expect the bulk of the changes to be in the wp_options table.
I have searched all sql entries in the database for the "domain name" (as was showed on Super Admin/Sites/Edit: "Domain") beginning with https with all kind of greps and subs in all combination of my domain names, but did not found any static entry.
After all, I revised my wp_config.php and also tried to switch off FORCE_SSL_ADMIN and FORCE_SSL_LOGIN to totally disable SSL on the sites, but had no affect - I could only reach my admin pages just via SSL on port 443, which lead to review my Apache config.
Solution: the VirtualHost config file was screwed up somehow and the entry on port 80 also had some entries of SSLCertificate pointing to a self-signed cert. Sorry for the trouble folks!
It seems that using the define('RELOCATE') command is a convenient tool to perform site development using a local database and webserver, then to upload into production. Otherwise, its necessary to perform SQL REPLACE commands to update all the URLs in the posts, media and other content.
The Wordpress codex specifically states that it must be removed, but occasionally after removing, the links revert back to the dev server. Is there a reason for removal? it doesn't seem that security should be the issue, perhaps performance?
Thanks,
Jonathan
The reason you remove it is because define('RELOCATE',true); will point every visitor of your site to the admin login.
If you are still getting re-directed to the dev server then you need to re-configure your database.