WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#10898 closed defect (bug) (wontfix)

direct theme install error is not reported

Reported by: foresto Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: dev-feedback close
Focuses: Cc:

Description

I just spent a few hours banging my head against a wordpress 2.8.4 installation which was mysteriously failing to accept a theme upload through the web UI. Instead of accepting the upload, it kept giving me a "failed to connect to ftp server" message and prompting me for ftp credentials. This was odd, because other installations simply accepted my upload and installed it.

After some experimentation, here's what seems to be going on:

  1. Wordpress tries accepting my theme file and installing it directly (from within the web server process).
  1. If that fails, Wordpress falls back to installing via ftp.

Problem: It never tells me the cause of the original failure, or even that there was a failure in the first place!

In this case, the original failure turned out to be related to file ownership in the wp-admin directory. Regardless, the failure should yield a helpful error message so the sysadmin can fix it, not just pretend that nothing went wrong and move on to ftp as if that was the only way to install a theme.

Change History (8)

comment:1 dd325 years ago

  • Keywords reporter-feedback added

Can you please give an example of your install environment in order to duplicate the issue?

ie. files were owned by apache:apache instead of user:user and caused XYZ to happen. On a server running Linux w/ ProFTPD and PHP 5.3

Also, Does this differ from your other report #10895, or is it likely these were down to the same issue on your end?

comment:2 dd325 years ago

In this case, the original failure turned out to be related to file ownership in the wp-admin directory. Regardless, the failure should yield a helpful error message so the sysadmin can fix it, not just pretend that nothing went wrong and move on to ftp as if that was the only way to install a theme

The only way to "fix" that is to change the way the server is setup and to use suPHP/SuExec, The first port of call is to write directly to the files if it is safe to do so, If the files are owned by a different user than the current process (group settings are ignored for other reasons) then this method cannot be used, And WordPress switches to using the FTP methods.

it kept giving me a "failed to connect to ftp server" message and prompting me for ftp credentials

Then that means your FTP server was rejecting your login, It could be due to you selecting SSL when the server doesn't support SSL, or similar.. All WordPress knows is your ftp server has said no. Can you check your server logs (If you've got access to them) to see why the server rejected your credentials? (Or if it even connected?)

comment:3 dd325 years ago

  • Component changed from General to Upgrade/Install

comment:4 dd325 years ago

  • Milestone Unassigned deleted
  • Resolution set to invalid
  • Status changed from new to closed

Switching to FTP in the case that the Filesystem Permissions are too restrictive for direct access is not a bug. Reporters problem is related to a FTP connection issue. Reporting that its using FTP instead of Direct isn't really needed due to the niche cases where it can be used. Same goes for the SCP transport, We dont warn users that they could use SCP if they install the correct PHP extension..

comment:5 foresto4 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

To clarify, the bug I'm reporting has nothing to do with ftp. I know why the ftp login failed; it was expected. The bug here is that Wordpress never tells the admin why the "first port of call" failed, or even that it failed at all, so he has no good way of knowing what to do about it. Fixing this would not require suphp or suexec, but simply making Wordpress display some text explaining that it won't write directly to the filesystem because it believes file ownership makes it unsafe to do so. The admin could then make an informed decision about what to do.

I'm re-opening this report because the original resolution seems to come from a misunderstanding of the problem.

comment:6 dd324 years ago

  • Keywords dev-feedback close added; reporter-feedback removed
  • Milestone set to Unassigned

I understood exactly your report when i closed it. Giving the user notification that one of several methods doesnt work on their server is not something that I feel should be done.

The same happens with the HTTP client, one of 5 methods is chosen depending on what the server supports.

The idea is to make things "just work" for the majority of people, If that means Direct access is not available (As it is not available on 95% of shared hosts) then FTP is used as a fallback. If Direct access is available, its used, but, 90% of users are not going to be the type to "correct" it, as its a server setup issue.

In my opinion: The direct checks should fail silently and move onto the next method in the priority queue, Thats what the queue is there for.

comment:7 dd324 years ago

As an addition: SSH2 SCP is also offered for upgrades, But its only offered if WordPress doesnt have Direct access AND the required PHP modules are enabled - Not too common - Its mainly used by those who understand what WordPress has to offer them

comment:8 scribu4 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

Agree with dd32 on not including notifications by default.

The same strategy is used for making remote HTTP requests.

A sysadmin type user can install a plugin that displays various information for debugging purposes.

Note: See TracTickets for help on using tickets.