thanatica2

I don’t expect any core developers here frequently. But moderators ever more so (hey there). Just saying.

Just don’t be impolite about it (not you, esmi). I don’t see where I insulted anyone directly before my comments were calling “whining”. I may be “just a user”, but being treated like that is uncalled for even if I was a little frustrated at the time.

No response, you are taking it easy.

Look, I’m reporting a problem here. If you don’t want to get it fixed, that’s your problem, not mine. But being a little bit grateful for the effort I took to report everything and even pointing out a possible solution, doesn’t kill you.

But instead, I’m whining.

You want this to be the very last bugreport from my end?

The topic referenced doesn’t provide a solution, and since it was a long time ago, it made more sense to start over and give WP all the benefit of the doubt.

I was wrong, because the problem still existed, and still exists to this day. So whether or not I have reported this problem before, is irrelevant; the WP developers have done nothing to solve it.

Commenting out the line I quoted is a working solution, and I see no reason why it would cause further problems. You see, when an application has managed to create and write to a file, checking its owner is pointless. WP does not *need* to own its files, and I certainly don’t want it to.

Ah. Right. I must say, I’m little little dissapointed with WP’s “logic” to determine whether a file is writable.

It seems that when it finally has managed to create and write to a file, it still isn’t satisfied and goes all out:
if ( getmyuid() == @fileowner($temp_file_name) )
To check whether the current user is the file’s owner. This cannot happen in my setup. The file’s owner is not the current user, even if that user created the file. WP should not expect this to always happen and fail if it doesn’t.

In my setup, any file, no matter which user creates it, will get the owner the same as the owner of the webroot directory. The assigned group is “www” (which includes “www-data”: apache’s user). This works like a charm and does not pollute the file ownership all over the place.

Now, why does WP need to do this silly additional check, if it has already confirmed it can write to a created file??

Okay, I may have discovered something here.

This is in /wp-admin/includes/file.php :

if ( ! $method && function_exists('getmyuid') && function_exists('fileo$
                if ( !$context )
                        $context = WP_CONTENT_DIR;
                $context = trailingslashit($context);
                $temp_file_name = $context . 'temp-write-test-' . time();
                $temp_handle = @fopen($temp_file_name, 'w');
                if ( $temp_handle ) {
                        if ( getmyuid() == @fileowner($temp_file_name) )
                                $method = 'direct';
                        @fclose($temp_handle);
                        @unlink($temp_file_name);
                }
        }

This is wrong, because the script check whether the newly-created tempfile is owned by the user that apache is running as. This will never happen in my scenario.

Why does a newly-created file need to be owned by the user apache is running as? I don’t want or need that, and neither does WordPress. By creating a file (and having it succeed) write-access is proven to be in order. No need to see who owns the file.

Can this please be fixed?

What does that have to do with the address field type?

btw, with “performance profile from start to end” I mean the performance profile from the very first hit to the server, to the point of starting to send the first byte to the client. So everything within the serverside execution time I’d like to see, because that’s what slowing the pages down.

Thanks, I ran the tool and it gave me a score of 79. Some improvements are still pending, but the thing is, this tool checks for issues on the frontend. It doesn’t (and can’t) check for speed issues that exist on the server, i.e. in PHP code, MySQL, internal caching, or otherwise…

That’s why I would like to somehow get a detailed performance profile from start to end, to eliminate bottlenecks *on the server*.

Btw, I already enabled the query cache on MySQL (the WTF here is that it’s disabled by default) but it shaves off almost nothing. For now I can just eyeball the execution time from FireBug (time to first byte sent to the browser) and it did go down by maybe 10 or 20 ms.

That still leaves a whopping 480ms execution time, at least 400 of which appears to belong to WP.