34 replies to this topic

[rbmatt]

hechacker1, on Jan 8 2006, 04:52 PM, said:

I already implemented the strip_tags function and it is working beautifully. But now I need to make it configurable so that the user can decide what tags to keep; which will probably only be the <img> and <p> tag.

strip_tags has a second parameter to allow certain tags. See http://us3.php.net/manual/en/function.strip-tags.php

[hechacker1]

rbmatt, on Jan 8 2006, 01:24 PM, said:

strip_tags has a second parameter to allow certain tags. See http://us3.php.net/manual/en/function.strip-tags.php

yeah, that is what i meant.. I wanted to keep some of the formatting that I know doesn't break the layout, like <img> and <p>. But I'm just gonna add a variable $strip_tags = ' ' that will let you decide what to keep. I'll put some reasonable defaults.

and while i'm at it, i might as well figure out how to remove a lot of the whitespace, since whitespace is considered as part of the length and gets stripped, leaving out content. some kind of filter that removes all empty spaces of "xx" two length, leaving "x" one length alone?

Edited by hechacker1, 09 January 2006 - 12:14 AM.

[rbmatt]

hechacker1, on Jan 8 2006, 08:03 PM, said:

and while i'm at it, i might as well figure out how to remove a lot of the whitespace, since whitespace is considered as part of the length and gets stripped, leaving out content. some kind of filter that removes all empty spaces of "xx" two length, leaving "x" one length alone?

Use a regular expression via preg_replace(). Something like:
$yourString = preg_replace('/\s\s+/', ' ', $yourString);

[hechacker1]

rbmatt, on Jan 8 2006, 04:22 PM, said:

Use a regular expression via preg_replace(). Something like:
$yourString = preg_replace('/\s\s+/', ' ', $yourString);

thanks for the reply. i'll try it out and see how it affects the html code. this is only a problem for when the content on the page is preceeded by a lot of empty space, and usually it ends up that the white space is displayed and the content gets cut short.

btw, I made it back to UCSD fine.. loving my 100mbit connection again (internet 2)

Edited by hechacker1, 09 January 2006 - 07:14 AM.

[rbmatt]

hechacker1, on Jan 9 2006, 03:13 AM, said:

thanks for the reply. i'll try it out and see how it affects the html code. this is only a problem for when the content on the page is preceeded by a lot of empty space, and usually it ends up that the white space is displayed and the content gets cut short.

That should replace any two or more white spaces with one.

hechacker1, on Jan 9 2006, 03:13 AM, said:

btw, I made it back to UCSD fine.. loving my 100mbit connection again (internet 2)

I'm headed back to UT today, so I know what you mean

[hechacker1]

i'm just giving another update. I recently switched to a new webhost (cause I needed more than 10GB a day of bandwidth) and my DNS is currently resolving to the new host.

I've already successfully imported my etomite database into the new host and etomite runs fine on it with Fast-CGI and php5.

but until the transition is complete, I can't continue with the snippet development since my files were all located on the server.

in a day or so i think i'll put the final revision here so you guys can test it and catch any obvious bugs and mistakes.

[Mark Kaplan]

hechacker1, on Jan 10 2006, 10:36 PM, said:

in a day or so i think i'll put the final revision here so you guys can test it and catch any obvious bugs and mistakes.

Can't wait to see it!

[hechacker1]

Ok, here it is!

Well, all the instructions are provided in the livesearch.php file. Also, this version assumes you will be using it outside of etomite, not in a snippet form. I think the external php method will provide most users with a faster experience.

However, in the next version i'll put in the simple code with a variable allowing the livesearch to be run in a snippet. It just takes more work though (with the empty [*content*] page).

Attached Files

•  livesearch.zip   14.4K   59 downloads

[hechacker1]

hechacker1, on Jan 16 2006, 06:50 PM, said:

Ok, here it is!

Well, all the instructions are provided in the livesearch.php file. Also, this version assumes you will be using it outside of etomite, not in a snippet form. I think the external php method will provide most users with a faster experience.

However, in the next version i'll put in the simple code with a variable allowing the livesearch to be run in a snippet. It just takes more work though (with the empty [*content*] page).

did anybody else give it a try? i'm curious to know before I release a broken snippet. now i'm off to get RTM!

[Ralph]

hechacker1, on Jan 17 2006, 05:30 PM, said:

did anybody else give it a try? i'm curious to know before I release a broken snippet. now i'm off to get RTM!

I liked the way it worked when I tested it on your site but haven't had a chance to give it a try on my site, for obvious reasons...

[hechacker1]

Ralph (rad14701), on Jan 17 2006, 01:43 PM, said:

I liked the way it worked when I tested it on your site but haven't had a chance to give it a try on my site, for obvious reasons...

yeah, well thanks! especially for RTM.

btw, I already did the upgrade, it took less than a minute.

I'm curious though, what are those new variables about the parser? I've noticed that my front page renders slightly more slowly, like .1 instead of .006

and my snippet still works.

EDIT: these variables?

$etomite->snippetParsePasses = 5; # Original default: 3
$etomite->nonCachedSnippetParsePasses = 5; # Original default: 2

Edited by hechacker1, 17 January 2006 - 10:02 PM.

[Dean]

Those variables are for the etomite parser - its the amount of times that the parser passes over a page scanning for snippets it hasnt already parsed

[Ralph]

hechacker1, on Jan 17 2006, 06:01 PM, said:

yeah, well thanks! especially for RTM.

btw, I already did the upgrade, it took less than a minute.

I'm curious though, what are those new variables about the parser? I've noticed that my front page renders slightly more slowly, like .1 instead of .006 

and my snippet still works.

EDIT: these variables?

$etomite->snippetParsePasses = 5; # Original default: 3
$etomite->nonCachedSnippetParsePasses = 5; # Original default: 2

The two variables you have listed have always been in the parser, they have merely had the values increased but that shouldn't effect rendering times... If you want to get some more speed I'm going to be posting a trimmed version of the index.php file which doesn't have all of the documentation remarks, which mainly document the API functions better, and also has the logging portion removed for those using alternate methods of statistics gathering... If you're really looking for lean and mean you could remove any API functions that you know you will never use as they could always be added back in later...

[hechacker1]

btw, has enough changed in the RTM to warrant me to change the livesearch etomite class included? I did some trimming in there and it still seems to work with RTM at least.

I plan to do some more trimming to make the livesearch even faster. Every little fraction of a second counts..

btw, what has changed in RTM that increased the page generation for my site? Just more commenting? Or did you add functions?

i've noticed that secondary pages that don't have the News Snippet are faster, like 0.06s , but the main page renders about 0.1s. Before RTM it was around 0.06 to 0.002s.

then again.. it's not like the users can really see that anyways

[Ralph]

hechacker1, on Jan 18 2006, 05:59 PM, said:

btw, has enough changed in the RTM to warrant me to change the livesearch etomite class included? I did some trimming in there and it still seems to work with RTM at least.

I plan to do some more trimming to make the livesearch even faster. Every little fraction of a second counts..

btw, what has changed in RTM that increased the page generation for my site? Just more commenting? Or did you add functions?

i've noticed that secondary pages that don't have the News Snippet are faster, like 0.06s , but the main page renders about 0.1s. Before RTM it was around 0.06 to 0.002s.

then again.. it's not like the users can really see that anyways 

The additional comments add about 20k to the size of your index.php file but I doubt that the comments are the culprit although they may be a contributing factor... One item that may be responsible for marginally increased page rendering times is the fact that there is more cached information being stored now than before... Regardless of whether you have caching enabled or not Etomite uses cache, it's just a matter of whether rendered pages are cached or not that the setting effects... In previous releases only alias and id records were stored in the cache for pages having aliases... Now all pages have information stored in the cache for use by internal functions... This may lead to very small increases in render times but nothing too serious... The benefits outweigh the differences in load times overall...