Wedge

As long as it works and works even for actions added to the list through hooks (e.g plugins), changing to /do/something would be neat.

Done here as you can see.

Adding new URL schemes through hooks is no longer possible with my current code, though... But hopefully it'll be (nearly) doable once I commit. I'd like to clean up my code now, and commit something for a change... ;)

So no caching?

On Pretty URL's by vb I have done allot of modifications to the code. I have reported some of what I have done to his code back to him hoping it will get implemented. Some does and some doesn't. However I figured it easier to cache url's with SMF caching instead of using the DB. At least this way I can let old data just die, the database option didn't allow for this. Also it will serve as a big performance boost if the page ever becomes the center of attention.

I have also removed index.php from the urls with the mod. Added one little extra rule to the source. Among that I have also added allot of extra rules for other mods.

Separately though I have made all old urls illegal and display a 404 page. I have found through access logs that allot of bots look for say action=, topic= or board= to identify SMF.

The other benefit of using SMF's caching is that if you're using something like memcached or APC, it transparently caches *there* rather than in the DB without any code change on your behalf.

That reminds me I need to do other caching changes, actually.

Wedge already does topic/board name caching (I need to add category name caching as well...), which represents the single biggest performance savings you could get. There's also a mini-cache inside the replacement callback (i.e. if a URL was already converted earlier in the page, we won't even bother to re-calculate what little data needs to be re-calculated).

What I'm not convinced with, is the global cache that stores every single URL to the cache... And I already added some warnings in the admin to discourage its use. And I'm considering dropping it entirely.Just wanted to say... Pretty URLs is NOT vb's. Definitely not! Dannii wrote it (and I wrote some small parts of it, or more precisely, I suggested improvements to Dannii because at the time I had no experience with collaborative programming, and I never used the SVN access he gave me on Google Code). He gave it to vb after he decided to retire from it, and forgot to offer it to me first (for which he apologized, so that's okay, it wasn't against me.) vb did absolutely nothing for PURLs, save for a few minor bug fixes. In fact, the mod is available in a BSD license so he couldn't do the usual things he does with mods he inherits (i.e. resell them!)

The PURLs in Wedge is based upon the version I rewrote for Noisen many years ago. All in all, it has very little to do with the original mod, except that I kept its name for simplicity, and it still uses the same basic techniques (going through all links to store them, extracting topic IDs, querying their names, and going through all links against to replace them.)But how did you do that...? One file per URL? That would incur a lot of disc writing/reading... One file per page?Can even be done with a str_replace... :)
$buffer = str_replace('"' . $scripturl . '", '"' . $boardurl . '"', $buffer);
Of course it's not the exact not I had in my code... And I'm doing it differently these days anyway (stripping the index.php directly when initializing $scripturl, which might create issues with plugins if they're not careful, so I'm still unsure I'll be doing that forever...)Hmm... But if you used to have a purl-free forum, you're basically telling Google to go away...

On SMF caching I cache 1 file per page, it would be too much of a waste 1 file per URL. I figured there are only going to be a few pages hit often and allot of pages not so often, so I believe it will even itself out using this method.

On to the 404 thing, the forum has always been a Pretty URL forum, so Google or any other search engine does not know the old urls.

However though, I had bad performance when I started but had to work on allot of aspects to get it up to par. The DB cache system though that it had was the worst feature, the board and topic cache in the db was good but the other url cache was just junk.

Sorry I don't know the history of the mod that much. I hardly even stop by SMF though or keep up with the mods they release there. I hate trying other peoples mods also, usually full of bad coding anyways, but I gave a few a try to get a site up and ready fast. Usually after a while I end up make the system incompatible for future updates, don't care though file comparison tools help allot here, maybe more work but worth it to see if there is any valuable code updates. Getting off topic here though... :whistle:

I don't know. I'm not sure this is for the best... We're talking about a feature that takes on average a hundredth of a second to execute (it's about half the time of the entire ob_sessrewrite execution time IIRC), perhaps two at the most, and caching this would logically save even less time... Then again, most of the cache calls in Wedge/SMF are done to save a few milliseconds only... But they usually don't have to target a wide range of URLs or anything.Then I guess you're good, indeed...Yeah, that's the main issue really... I'm still very much tempted to remove it -- but I'm wary of removing it to replace it with something I like even less.Neither do I... Basically, I got in touch with Dannii back in late '07, helped out a bit, he offered a dev spot at google code, I never used it because of my lack of knowledge of svn, then my own version started diverging from his, and around '10 (?) he made it BSD and gave vblamer a dev spot and the 'keys' to the SMF mod page. By that time, my own code was already too different anyway...When you're running a forum, you don't always think of updating it... I personally rarely do, either.
I think we should write some kind of 'automatic updater' for plugins and Wedge, disabled by default or something, with the ability to install only the 'proven' updates of Wedge (or maybe also cutting edge versions?), something like that... We could simply retrieve the gzip file, extract it somewhere, and copy the tree structure...

That would be cool!! :o

I'm going to love writing a routine to download the zip, upload it from a temporary file, unpack it file by file, upload each one to the server via FTP and hope to hell that we don't have permissions fuck-ups along the way.

Notifying users is good. Making it one-click is a VERY BAD IDEA. It's right up there with shitty plugins as why people get hacked.

As cool as it might be, the nightmare of doing it is enough to put me off doing it. Other systems do not have auto updating tangles, I don't entirely see why we should, especially since it's more likely to fuck you about than not.

WordPress had or has a one click update, Nightmare on shared hosting and a resource hog and SLOW. I(t is a shame most shared hosts dont let users do wget and unpack shit this of all the saved bandwidth world wide.

It works like a charm instead.. The security concerns are valid, but it works really really well.

It doesn't 'work like a charm' for competent sysadmins who don't use FTP - it only works for me if I unsecure WP installations.

If you think for one moment I'm going to trade security for functionality, you're very much mistaken.

Well... Then you could disable it ;)
Thing is, 90% of all SMF installs are 'insecure' per se if you'd like... And perhaps they don't mind, even knowing so. If this at least allows them to do automatic upgrades...

:edit: Testing edits...

I'm sorry, I'm not prepared to accept being insecure by default just because people are too lazy to do some work themselves occasionally.

Here's the thing: other platforms don't have one-click upgrades, and they're absolutely happy with this for exactly the same reason I am.