How to install a new theme?

Discussion:

Steve Litt

2014-02-24 18:59:56 UTC

Hi all,

I'm running WordPress on Ubuntu 13.10, installed via Ubuntu's normal
package. From http://127.0.0.1/blog/wp-admin/themes.php , I go to the
Install Themes tab, search for ryu, click "Install Now", and I get "To
perform the requested action, WordPress needs to access your web
server. Please enter your FTP credentials"

I'd rather not give someone FTP or sftp access, and besides, I'm behind
a firewall, but no problem: I just downloaded ryu myself, unzipped it
into /usr/share/wordpress/wp-content/themes/ryu in exactly the same way
as the
preexisting /usr/share/wordpress/wp-content/themes/twentythirteen, but
when I went to WordPress, ryu wasn't shown as an installed theme. No
problem, I logged out and back into Wordpress, same problem. I stopped
and started Apache: Same problem. I rebooted the computer. Same problem.

Twentytwelve is installed too. I think I installed it yesterday without
these problems, but I'm not sure. Anyway, I grepped the
entire /usr/share/wordpress tree for "twentytwelve" and, other than the
files inside the theme itself, I came up with the following files:

* wp-admin/includes/update-core.php
* wp-content/languages/*.mo
* wp-includes/class-wp-theme.php

At that point I decided to quit experimenting and ask for help. Ideally
I'd like to be able to install a new theme *both* the automatic way
from my WordPress site (but without giving WP an (s)ftp login), and by
downloading the theme .zip and incorporating it into my installation.

I read on the Internet various descriptions of the "ftp credentials"
problem as being a permissions problem or something you fix with chown,
but all these posts conflicted with each other in the details so I
decided to ask here. For all I know it's just because my Ubuntu machine
is behind a firewall.

Thanks,

Steve

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

John Blackbourn

2014-02-24 19:06:16 UTC

Permalink

Hi Steve,

After unzipping the theme into "ryu", is there an "ryu" directory
inside it? If so you'll need to move the files inside it up one level.

Eg. this is wrong:

ryu
- ryu
- index.php
- style.css

This is right:

ryu
- index.php
- style.css

If that's not the problem then I've no idea what's wrong. Installing a
theme is very straight forward. The only other thing it could be is an
opcode cache, but that should get flushed when restarting the server
or the machine.

John

Post by Steve Litt
Hi all,
I'm running WordPress on Ubuntu 13.10, installed via Ubuntu's normal
package. From http://127.0.0.1/blog/wp-admin/themes.php , I go to the
Install Themes tab, search for ryu, click "Install Now", and I get "To
perform the requested action, WordPress needs to access your web
server. Please enter your FTP credentials"
I'd rather not give someone FTP or sftp access, and besides, I'm behind
a firewall, but no problem: I just downloaded ryu myself, unzipped it
into /usr/share/wordpress/wp-content/themes/ryu in exactly the same way
as the
preexisting /usr/share/wordpress/wp-content/themes/twentythirteen, but
when I went to WordPress, ryu wasn't shown as an installed theme. No
problem, I logged out and back into Wordpress, same problem. I stopped
and started Apache: Same problem. I rebooted the computer. Same problem.
Twentytwelve is installed too. I think I installed it yesterday without
these problems, but I'm not sure. Anyway, I grepped the
entire /usr/share/wordpress tree for "twentytwelve" and, other than the
* wp-admin/includes/update-core.php
* wp-content/languages/*.mo
* wp-includes/class-wp-theme.php
At that point I decided to quit experimenting and ask for help. Ideally
I'd like to be able to install a new theme *both* the automatic way
from my WordPress site (but without giving WP an (s)ftp login), and by
downloading the theme .zip and incorporating it into my installation.
I read on the Internet various descriptions of the "ftp credentials"
problem as being a permissions problem or something you fix with chown,
but all these posts conflicted with each other in the details so I
decided to ask here. For all I know it's just because my Ubuntu machine
is behind a firewall.
Thanks,
Steve
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Nikola Nikolov

2014-02-24 19:12:49 UTC

Permalink

Hi Steve,

I don't think that the problem should be that you are behind a firewall -
after all you're accessing localhost at 127.0.0.1 so I don't think that the
firewall should matter.

The problem with WordPress asking for FTP credentials is that the
permissions for wp-content do not allow it to write files and directories.
That means that if WordPress(read PHP) is run as the www-data user then the
permissions that would allow it read/write access to the wp-content
directory are 0755. From a terminal you can run the following commands(omit
the "sudo" part if you are logged-in as root):

cd /var/www/blog/
sudo chmod 0755 wp-content/
cd wp-content/
sudo find -type f -exec chmod 0644 {} \;
sudo find -type d -exec chmod 0755 {} \;

What the above would do is to change the permissions on the wp-content
folder to ones that allow WordPress read/write access to it. After that we
would give write access to all files and directories within wp-content -
you don't have to do that, but if you want to be able to use the
theme/plugin editor you need to do so.

After you do that, open Files(the file manager of Ubuntu 13.10), go to
/var/www/blog/wp-content/themes/ and manually delete the theme folder. Then
you should be able to install the theme through WordPress(which will
automatically give it the right permissions and ownership).

If you're only going to use the installation for development purposes, you
can do what I tend to do:
- Change the group to which of all files and directories belong to a group
that my current user belongs to(usually the same as the username).
Alternatively you can just add your user to the www-data group.
- Change the permissions of all directories to 0775 and the permissions of
all files to 0664.

This allows me to change files via a text editor and allows WordPress to
write all of the files that it wants to.

On Mon, Feb 24, 2014 at 9:06 PM, John Blackbourn

Post by John Blackbourn
Hi Steve,
After unzipping the theme into "ryu", is there an "ryu" directory
inside it? If so you'll need to move the files inside it up one level.
ryu
- ryu
- index.php
- style.css
ryu
- index.php
- style.css
If that's not the problem then I've no idea what's wrong. Installing a
theme is very straight forward. The only other thing it could be is an
opcode cache, but that should get flushed when restarting the server
or the machine.
John

_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Otto

2014-02-24 19:34:10 UTC

Permalink

Post by Nikola Nikolov
The problem with WordPress asking for FTP credentials is that the
permissions for wp-content do not allow it to write files and directories.

It's more complex than just permissions.

Consider the most common case:
- User has username of "bob".
- Webserver runs as "www-data".

This means that the WordPress PHP files are owned by "bob", but the
webserver executes as the "www-data" user. Now, whether or not the
webserver has permissions to write to those files and/or directories is
really irrelevant. Any files that the webserver creates are going to be
created as being owned by the "www-data" user, not by "bob".

In a shared hosting environment, where there might also be "alice" and
"carl" running web software of their own, this is a security issue. If
Bob's files are owned by "www-data", then Alice can write code herself, run
it through the webserver (as "www-data") and thus access Bob's files
inappropriately. Bob doesn't like that one bit.

So, WordPress protects against this scenario. When it tries to write files,
it makes certain that the act of writing a file is not just possible due to
permissions, but also that the resulting file will be owned by "bob", and
not by "www-data". It does this by the simple method of writing a test
file, and comparing the ownership of the file to the pre-existing WordPress
PHP files already on the system (specifically, against the
/wp-admin/includes/file.php file, where the get_filesystem_method()
function is).

If the file owners don't match, then it decides not to use the "direct"
writing approach, and switches to one of the other methods instead, like
FTP or SSH. In these methods, it can use the credentials given to make a
connection back to the machine (loopback, basically) and authenticate in
the process. Any files it writes through this connection will get the
ownership of the new credentials ("bob").

The point is to make sure that the files end up being owned by "bob",
because that's the secure choice. On a multiuser environment, ownership
matters more than permissions.

If you want to eliminate that FTP prompt and use the "direct" method in a
multi-user environment, install "suphp" instead of the normal PHP, or use
one of the many methods to run your PHP process using "suexec" permissions.
Google for "fastcgi suexec" for examples of how to do this in your
environment. In this sort of setup, the PHP process switches itself to be
running as "bob". This is secure because "alice" can't write a program on
her environment as "bob", so her processes run as "alice" and still cannot
access Bob's files.

-Otto

Steve Litt

2014-02-24 20:28:03 UTC

Permalink

On Mon, 24 Feb 2014 13:34:10 -0600

On Mon, Feb 24, 2014 at 1:12 PM, Nikola Nikolov

Post by Nikola Nikolov
The problem with WordPress asking for FTP credentials is that the
permissions for wp-content do not allow it to write files and directories.

It's more complex than just permissions.
- User has username of "bob".
- Webserver runs as "www-data".
This means that the WordPress PHP files are owned by "bob", but the
webserver executes as the "www-data" user. Now, whether or not the
webserver has permissions to write to those files and/or directories
is really irrelevant. Any files that the webserver creates are going
to be created as being owned by the "www-data" user, not by "bob".
In a shared hosting environment, where there might also be "alice" and
"carl" running web software of their own, this is a security issue. If
Bob's files are owned by "www-data", then Alice can write code
herself, run it through the webserver (as "www-data") and thus access
Bob's files inappropriately. Bob doesn't like that one bit.
So, WordPress protects against this scenario. When it tries to write
files, it makes certain that the act of writing a file is not just
possible due to permissions, but also that the resulting file will be
owned by "bob", and not by "www-data". It does this by the simple
method of writing a test file, and comparing the ownership of the
file to the pre-existing WordPress PHP files already on the system
(specifically, against the /wp-admin/includes/file.php file, where
the get_filesystem_method() function is).
If the file owners don't match, then it decides not to use the
"direct" writing approach, and switches to one of the other methods
instead, like FTP or SSH. In these methods, it can use the
credentials given to make a connection back to the machine (loopback,
basically) and authenticate in the process. Any files it writes
through this connection will get the ownership of the new credentials
("bob").
The point is to make sure that the files end up being owned by "bob",
because that's the secure choice. On a multiuser environment,
ownership matters more than permissions.
If you want to eliminate that FTP prompt and use the "direct" method
in a multi-user environment, install "suphp" instead of the normal
PHP, or use one of the many methods to run your PHP process using
"suexec" permissions. Google for "fastcgi suexec" for examples of how
to do this in your environment. In this sort of setup, the PHP
process switches itself to be running as "bob". This is secure
because "alice" can't write a program on her environment as "bob", so
her processes run as "alice" and still cannot access Bob's files.
-Otto

Thanks Otto,

As a diagnostic test,
within /usr/share/wordpress/wp-admin/includes/file.php, I modified the
get_filesystem_method() function by putting $method = 'direct'; after
the code that tested the temp file's owner against the return value of
getmyuid(), and indeed, it no longer asked me for my ftp creds, and
indeed started installing something (I was trying to install k2).
However, Wordpress then aborted with "Could not create
directory. /var/lib/wordpress/wp-content/upgrade". So I created the
upgrade dir and it got a little farther, chowned it www-data.www-data
and it got farther but griped that couldn't write
to /var/lib/wordpress/wp-content/themes/k2, so I chowned themes
www-data.www-data, and it succeeded installing, but the preview was the
dreaded blank preview.

So, all this proves that what you said is true. To get it to work (in a
diagnostic mode), I probably need to fix a few other things. And then
figure out the real solution :-)

I'm curious why the Ubuntu 13.10 packager installed Wordpress has
everything owned and grouped by root, with write permissions only for
root. Is their package defective?

This stuff is exactly why I chose to learn all of this on my own
personal machine before making a blog on my web host. Thanks for this
detailed info, Otto.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

Otto

2014-02-24 21:11:44 UTC

Permalink

Post by Steve Litt
I'm curious why the Ubuntu 13.10 packager installed Wordpress has
everything owned and grouped by root, with write permissions only for
root. Is their package defective?

It is my considered opinion that using any distribution's "packaged"
version of WordPress is a bad idea. I don't know why they do this sort
of thing to begin with.

Install the webserver, php, mysql, etc. from your package manager of
choice. Then find the relevant public_html folder and put your own
copy of WordPress in there, directly from the zip or tarball from
WordPress.org.

Makes little to no sense to use a package manager for installing
WordPress, except that it might configure a database for you, which
takes all of a minute to do yourself.

-Otto

Steve Litt

2014-02-24 23:37:52 UTC

Permalink

On Mon, 24 Feb 2014 15:11:44 -0600

Post by Otto
Install the webserver, php, mysql, etc. from your package manager of
choice. Then find the relevant public_html folder and put your own
copy of WordPress in there, directly from the zip or tarball from
WordPress.org.
Makes little to no sense to use a package manager for installing
WordPress, except that it might configure a database for you, which
takes all of a minute to do yourself.

Madalin Ignisca

2014-02-24 23:45:35 UTC

Permalink

If you have a decent machine (Core2Duo or recent - no CodeDuo) then try
this: https://puphpet.com/

It will help you to get much more easier a proper development environment
to test and work. I never looked back since I found Vagrant and Puppet.

PS: Works on x64 only.

Post by Steve Litt
On Mon, 24 Feb 2014 15:11:44 -0600

Excellent, and just in time, as I was going to deinstall and reinstall
WordPress to try again. Where would I find documentation on how to do
the database config you speak of?
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

--
*Madalin Ignisca*
*web developer*
http://imadalin.ro/

Otto

2014-02-25 00:59:07 UTC

Permalink

Post by Steve Litt
Excellent, and just in time, as I was going to deinstall and reinstall
WordPress to try again. Where would I find documentation on how to do
the database config you speak of?

https://codex.wordpress.org/Installing_WordPress#Step_2:_Create_the_Database_and_a_User

-Otto

Steve Litt

2014-02-25 00:46:21 UTC

Permalink

On Mon, 24 Feb 2014 15:11:44 -0600

On Mon, Feb 24, 2014 at 2:28 PM, Steve Litt

Post by Steve Litt
I'm curious why the Ubuntu 13.10 packager installed Wordpress has
everything owned and grouped by root, with write permissions only
for root. Is their package defective?

It is my considered opinion that using any distribution's "packaged"
version of WordPress is a bad idea. I don't know why they do this sort
of thing to begin with.

* *
\ o /
\|/
| A W R I G H T ! ! !
/ \ _
/ \/
/
-

Thank you, Otto. It's amazing how easy it was once I followed your
advice, got rid of the Ubuntu installed WordPress, and unzipped the zip
file downloaded from wordpress.org, following the directions at
http://codex.wordpress.org/Installing_WordPress .

It took me about an hour, considering I was very careful in following
the instructions, and doing stuff not mentioned by the documentation,
like chown -R www-data.www-data blogg. Yeah, I spelled blogg with two
g's because I got a not found if I spelled it with one g, probably a
defective vestige of the Ubuntu Wordpress installation I blew away.

It took me two minutes to install a new theme, and doing so required no
brains at all.

Otto, thank you for giving me detailed, correct and topical technical
information that allowed me to do this.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

Steve Litt

2014-02-24 19:36:05 UTC

Permalink

On Mon, 24 Feb 2014 19:06:16 +0000

The preceding, which you label as "right" is how I did it. Its contents
looked pretty much like the twentytwelve and twentythirteen
directories, which *were* recognized.

Post by John Blackbourn
If that's not the problem then I've no idea what's wrong. Installing a
theme is very straight forward. The only other thing it could be is an
opcode cache, but that should get flushed when restarting the server
or the machine.

Yeah, I was figuring it was some kind of cache, which is why I
restarted everything. John, you've given me some valuable info: What I
was doing *should* have worked, and is the right way of doing it. So
now it's just a matter of getting Wordpress to conform to its
as-designed behavior.

Thanks

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance