Yup you're showing up as licensed now. :D

I could do with some help installing this and am prepared to pay for it, if anyone's interested?:)

Paul

If you are asking someone to do a job for payment, please post your request in teh Service Request forum.

almost working, but i'm having a problem with IE displaying 'glossary' links (set them up exactly per instructions):

http://img131.imageshack.us/img131/4564/gal8rp.jpg

it seems to appear fine in firefox (just showing the text under the link, no <td> code)..

tried rebuilding as well.

from the debug:

any ideas?

Looks like a bug... "Box style" (box_style) setting does not take when adding a new category. The category can be edited to fix it though.

Hey, what's with the vB versions you guys are claiming to be running?

MarcoH64: 4.5.0 Beta4
The Geek: 4.06

As far as I know, vB 3.5 is in beta now.

mkdevo - it looks like you are running in danger mode. Make sure its in safe mode and rebuild.

Thanks tom... ill look into it. :)

Geek,

You didn't envision people using it with more than 190 replacements? I would expect it to be very common to have more than that once you get rolling with it.

GAL 4 is substantially slower than GAL 3! It's an absolute show stopper. Even a dual Xeon system is brought to it's knees with hundreds of replacements.

In addition to adding extra features, did you mostly switch from simple string replacements to using regular expressions - or is there some other reason that it is substantially slower than the previous version?

Other than turning off the DB Cache and removing some replacements, what else can be done to speed things up?

How do I turn off GAL4 completely (disabled) without un-installing it? I don't see an option in the admin area.

Can replacements be disabled rather than removed?

Geek,

The large amount of CPU time seems to be spent in the regular expression searching of preg_replace().

Since 99.9% of the time, the replacement text is not present in any given post, how about pre-processing the list of replacements "text" fields to see if a simple string search using the quicker stristr() function finds the text in the post before adding it to the find/replacement array to be used by "the CPU hog" preg_replace() function? I would then expect the preg_replace() to usually only be working with a few search terms or less.

I think this would speed things up a lot when using hundreds of replacements.

Hi Tom,

The actual processing of the preg_replace is almost identical to the previous version (Especially if not using the DB cache). In fact, off the top of my head it IS the same.

Lets say that you have 190 GALS to check, you would then need to run 190 stristr´s THEN run the preg_replace on the results (for each post in the thread). Whether this has any cost implications, I couldnt say. Seems to me the ultimate solution would be to find a way to GAL the page results instead of on a post by post basis. The problem with doing that (as it is easily done) is the increased risk of GALing stuff you dont want GALed. If that could be done, you could cut the average preg_replace cost by an average 15 times.
If you want to give it a try, run the process_text function on the postbits after they are created.

As I mentioned before, I didnt envision 190 replacements at a go though I guess can easily see it happening now. The previous version would give you about as much overhead as this one would so I dont think it really has much to do with that.
Ill look into cost implications of the stristr or strpos when I start to migrate this to 3.5 however I think the real benefit would be by GALing the results instead of the post text.

HTH´s