chuyskywalker

Kill shortstat. I made that plugin and the 1.5 version is a beast. I’ve had numerous reports of it causing sever lag and memory issue. That’ll probably take care of it.

I’m very, very, very slowly updating for 2.0.

Soteke: I’m really not familiar with how localization works. The data I pull from hostip could be passed through a filter or what not, just really not sure how it works.

Reevo: The easiest way to clear the database is to jump into something like phpMyAdmin and delete the tables by hand. They should be called wp_ss_stats and wp_ss_search.

The download site is down. It’ll be back up soon I hope (I don’t have control over it though, so…)

Ksec: You are absolutely right ShortStat is not comprehensive — hence the “Short” ??

Also, if by “exclude yourself” you mean that your wp-admin/ pages are showing up, just redownload the plugin (v1.2). I fixed that problem.

Josepo: Hrm, it seems that the admin section detection was faulty for a few people. I’ve updated the plugin to v1.2 which should alleviate the problem. Let me know if that works…

Josepo: If I end up adding a page for options, I’ll put that one in there. But, I wonder, why do you not want to know what registered members are looking at?

Er, not actually a link I suppose…

macmanx: ooh, thanks! Forgot about adding it there.

Ksec: I’m not familiar enough to say what the other stats plugins do, or how they operate. I just made this one. :/

As for monthly stats, no it does not. From reading the ShortStat code it looks like most of the stats are just aggregate functions — meaning they have no timelimit. It just includes everything since it began tracking. Of course, the week list goes back one week from today — which is probably the only time sensitive element.

For tracking monthly stats I would recommend something more thurough, like AWStats which will analyze your Apache logs. It’s a far more detailed and overall analysis, since WP-ShortStat only tracks users and hits that occur in WordPress code. Oh, and it does monthlies. ??

Catching up to the tail of this issue…

I’ve been on this whole “login lag”/”dashboard delay” issue for a while. Bugs the living crap outta me. I see that little timer at the bottom go from “0.029 Seconds” to “18.09 Seconds”. Extremely frustrating and annoying.

So here’s a plugin:

Login Delay Stopgap

This plugin will hook into the shutdown action to update the three feeds (technorati, WP Dev, and WP Planet) every ten minutes so that when you login it’s already cached and ready to go.

“Oh noes,” you say, “but then my users get a 20second load time!” No, actually, because I tie into the “shutdown” hook, the feed update only happens *after* the data is sent to your visitors.

Also, I set it up so that this plugin runs no more than once every ten minutes (this way, high traffic sites won’t worry about their copy of MagPie fetching 3 rss feeds for every single visitor.)

Source to Login Delay Stopgap

You can either address them or not I guess, in the end the fallout will be wordpress’ problem.

the last time I checked this was made by humans, right, or did you all pass over into diety stutus?

So, wait, which part is going to be the downfall of WordPress? Is it the fact that WP devs are — apparently– gods, or this whole “full path disclosure” thing?

Wow, this thread got outta control, but at least you’re making it interesting to read!

Dextro: Perhaps I’m daft on this issue, but how is that comprimising data? Most home paths like that can be guessed — especially on shared hosting like <i>most</i> people have.

Aside from being an ugly error message, what paths does this lead or potential hacker down? Unless the hacker has an account on your shared server, and the server isn’t jailrooted (or whatever that technique is called) then I’m not aware of how this comes as useful information.

Enlighten me (us) ?

You may just be stuck then. Write your host? Maybe they’ll be cool and install it for you and give you SSH access.

I’m with ASO — and they did just that at customer request. Quick too, like, < 12 hour turnaround. Pretty awesome.

Apparently that is the issue here.

Hrm…

I think that’s a serious security problem.

I can’t see how this is 1) a security issue or 2) serious. It’s more like a “i don’t want people seeing my files” issue which should probably be decided on a site to site basis by those who care to lock it down. I would no recommend this to be a default.

somefool,

Actually, with a bit of PHP trickery, you could do this withouth SSH access. The real issue is if SVN is installed on your host or not.

Generall, using system() or exec() you can run code as if you were in SSH via a php script. Example:

<?php
echo exec('svn help');
?>

In fact, you might upload a simple php script just like that and see if it works.

Wait a sec. Exactly what is the security issue here? Am I reading this wrong, or are you upset that I can browse to youriste.com/wp-content/plugins/ and view what plugins you run?

So what? I click on a plugin and it errors out. Everything is PHP executeable, so no critical information is revealed. And what’s the harm in seeing what other people have installed?

I like the fact that I can browse most WP sites like this. It helps me to learn, and often times helps me out while I am troubleshooting a site.