Greetings,
Apologies for my seeming daft naivete.
I'm wondering if there any sort of conventions for using Wordpress on CentOS?
Generally until now, I have had users install Wordpress from tarballs on a case-by-case basis. This means that you can have several different versions of WordPress operating on a site.
With the RPM you have a version that can be consistent across multiple websites on one server.
Is this done through the use of symlinks, or is there some other, additional magic that gets put to use.
I've done a little searching of the Google genie, but I'm only led to webpages outlining installing Wordpress from tarballs.
Much thanks,
Max Pyziur pyz@brama.com
On Mon, 11 Nov 2013 18:46:33 -0500 (EST) Max Pyziur wrote:
I'm wondering if there any sort of conventions for using Wordpress on CentOS?
Is this what you're looking for?
Available Packages Name : wordpress Arch : noarch Version : 3.6.1 Release : 1.el6 Size : 3.4 M Repo : epel Summary : Blog tool and publishing platform URL : http://www.wordpress.org License : GPLv2 Description : Wordpress is an online publishing / weblog package that makes it : very easy, almost trivial, to get information out to people on the : web.
On Mon, 11 Nov 2013, Frank Cox wrote:
On Mon, 11 Nov 2013 18:46:33 -0500 (EST) Max Pyziur wrote:
I'm wondering if there any sort of conventions for using Wordpress on CentOS?
Is this what you're looking for?
Available Packages Name : wordpress Arch : noarch Version : 3.6.1 Release : 1.el6 Size : 3.4 M Repo : epel Summary : Blog tool and publishing platform URL : http://www.wordpress.org License : GPLv2 Description : Wordpress is an online publishing / weblog package that makes it : very easy, almost trivial, to get information out to people on the : web.
I already have it. I would like to know what are the conventions for using it, vs installing wordpress on a case-by-case basis from tarballs.
Thanks.
Max Pyziur pyz@brama.com
On Mon, 11 Nov 2013 19:05:52 -0500 (EST) Max Pyziur wrote:
I already have it. I would like to know what are the conventions for using it, vs installing wordpress on a case-by-case basis from tarballs.
I think you need to define your question a bit more clearly. If you already have the rpm installed, why do you think that you should also "install wordpress on a case-by-case basis from tarballs"?
On Mon, 11 Nov 2013, Frank Cox wrote:
On Mon, 11 Nov 2013 19:05:52 -0500 (EST) Max Pyziur wrote:
I already have it. I would like to know what are the conventions for using it, vs installing wordpress on a case-by-case basis from tarballs.
I think you need to define your question a bit more clearly. If you already have the rpm installed, why do you think that you should also "install wordpress on a case-by-case basis from tarballs"?
I'm sure that I expressed the question correctly in my original email; here it is again:
####################
Greetings,
Apologies for my seeming daft naivete.
I'm wondering if there any sort of conventions for using Wordpress on CentOS?
Generally until now, I have had users install Wordpress from tarballs on a case-by-case basis. This means that you can have several different versions of WordPress operating on a site.
With the RPM you have a version that can be consistent across multiple websites on one server.
Is this done through the use of symlinks, or is there some other, additional magic that gets put to use.
I've done a little searching of the Google genie, but I'm only led to webpages outlining installing Wordpress from tarballs.
########################
So, I can follow the necessary instructions for installing Wordpress from tarballs. But I run a multi-user, multi-virtual host server. Consequently, I'm wondering if it is possible to use the wordpress centos rpms, and utilize a mechanism such as symlinks for the sake of consistency and upgrades?
Thanks.
Max
On 12/11/13 10:46, Max Pyziur wrote:
Greetings,
Apologies for my seeming daft naivete.
I'm wondering if there any sort of conventions for using Wordpress on CentOS?
Generally until now, I have had users install Wordpress from tarballs on a case-by-case basis. This means that you can have several different versions of WordPress operating on a site.
With the RPM you have a version that can be consistent across multiple websites on one server.
Is this done through the use of symlinks, or is there some other, additional magic that gets put to use.
I've done a little searching of the Google genie, but I'm only led to webpages outlining installing Wordpress from tarballs.
Much thanks,
Max Pyziur pyz@brama.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
I've not tried the repo's or rpms, but i'm guessing if you install from them, the same process applies for updates with WP i.e. it's done from the WP web console and you would definitely want to check that after an install from those sources as they would be a bit behind.
Cheers Keith
On Tue, 12 Nov 2013, Keith wrote:
On 12/11/13 10:46, Max Pyziur wrote:
Greetings,
Apologies for my seeming daft naivete.
[...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
MP
I've not tried the repo's or rpms, but i'm guessing if you install from them, the same process applies for updates with WP i.e. it's done from the WP web console and you would definitely want to check that after an install from those sources as they would be a bit behind.
Cheers Keith
On 12/11/13 14:59, Max Pyziur wrote:
[...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
MP
Not sure what you mean exactly by what's the point of having RPMs? If you have multiple servers/sites then you can still deploy WP via a RPM or package management or if you have that many servers you should be using config tools like Puppet, so you could deploy the latest via such a tool.
But the same thing applies, you do the updating/upgrading of WP via the WP web-console, or at least you will need to at some stage. I think the latest version offers an automated security update feature now anyway.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In article 5281CB8C.1000604@winnetworks.com, Keith squeeze@winnetworks.com wrote:
On 12/11/13 14:59, Max Pyziur wrote:
[...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
MP
Not sure what you mean exactly by what's the point of having RPMs? If you have multiple servers/sites then you can still deploy WP via a RPM or package management or if you have that many servers you should be using config tools like Puppet, so you could deploy the latest via such a tool.
But the same thing applies, you do the updating/upgrading of WP via the WP web-console, or at least you will need to at some stage. I think the latest version offers an automated security update feature now anyway.
I don't know the answer, but I think I at least understand the question:
- how does the RPM of WP apply in a virtual-hosting environment? Or is it only applicable to a single site stored in /var/www/html?
- In the tarball mode of installation, each site in a vhosting system would have its own complete copy of WP within its own document root. Is it possible still to make use of the RPM instead, in this setup?
Cheers Tony
On Mon, Nov 11, 2013 at 10:59 PM, Max Pyziur pyz@brama.com wrote:
On Tue, 12 Nov 2013, Keith wrote: [...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
MP
Maybe the packages are meant for a different usage pattern than yours?
Packaging anything, but particularly web apps, involves making tradeoffs. For most people, package defaults provide a basic set of functionality (which can be adequate for most people), but there are some cases where a power user might have need to install them with other settings.
Your usage pattern as a hosting provider is on the "power user" end of the spectrum, and you should probably be using the tar file or even creating your own custom rpms so you can set it up as you need it.
❧ Brian Mathis
On 11/12/2013 9:44 AM, Brian Mathis wrote:
On Mon, Nov 11, 2013 at 10:59 PM, Max Pyziur pyz@brama.com wrote:
On Tue, 12 Nov 2013, Keith wrote: [...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
MP
Maybe the packages are meant for a different usage pattern than yours?
Packaging anything, but particularly web apps, involves making tradeoffs. For most people, package defaults provide a basic set of functionality (which can be adequate for most people), but there are some cases where a power user might have need to install them with other settings.
Your usage pattern as a hosting provider is on the "power user" end of the spectrum, and you should probably be using the tar file or even creating your own custom rpms so you can set it up as you need it.
❧ Brian Mathis _______________________________________________
To my knowledge, there has always been a 'central WordPress install' method. I 'assume' that is what this RPM does?
Aside from that... Plugin hell! The automated WP updates is really new and I am betting will break sites 'automatically'. We turn this feature off for the moment.
The issue is plugins. Most people run some plugins on their WP installations and some people run dozens. Each of these can be website critical, or IOW, if they don't work the site is totally broken. This happens far too often during an update to WordPress.
So, our method has been an extra fee added to hosting WP sites, so that we can monitor and do the upgrades, so we know they are done. We work with the client if there are conflicts with plugins. We do the update and then give the website a once over to try to find any broken 'features'.
It all depends on how kind you wish to be with your customers. (but I do hope the automated part can actually work... perhaps in the future at least?)
Best, John Hinton
On 12.Nov.2013, at 04:59, Max Pyziur wrote:
On Tue, 12 Nov 2013, Keith wrote:
On 12/11/13 10:46, Max Pyziur wrote:
Greetings,
Apologies for my seeming daft naivete.
[...]
I always install from the latest tarball from the WP site, as it's the latest at the time of installation. With regards to WP updates and versions, this is generally performed with it's own built in updating/upgrading mechanism which is the first thing you should check or do after install and on an ongoing basis - IMHO anyway.
Makes sense.
So what are the point of having RPMs if you can't apply it server-wide across multiple sites?
The problem with wordpress AFAICS is that $WP_PLUGIN_DIR is not stackable, i.e. you either have central plugins or you have per installation plugins.
In a central installation you want to install plugins in a central way. When doing a shared host you probably want to give your users the flexibility to install plugins themself. The algorithm would be look in the central plugindir first, if not found look in the local plugindir.
Wordpress does not support this. You have have only *one* directory. For a shared environment the epel rpm seems to be pointless.
-
Brian Mathis -
Frank Cox -
John Hinton -
Keith -
Markus Falb -
Max Pyziur -
tony＠softins.co.uk