salathe

Cheers MadTechie, I am a little cross-eyed. Apologies for the typo. :-)

Whilst the tone of the post may not be appropriate, the suggestion is a good one. There is an article linked in the forums rules (#17): How To Ask Questions The Smart Way. Inside that article there is a short section entitled, "How To Answer Questions in a Helpful Way". However useful that section of the linked article is, I doubt many reading the PHPFreaks rules would reach it! Maybe I didn't read the rules page thoroughly enough (it's possible!) but some guideline(s) on answering questions would be a useful addition, in my view.

The intention was to show that you don't use array_search with my code snippet. The if/isset block replaces your use of array_search.

Regarding the possessive quantifier, that's actually a typo but either way will work. I guess on the off-chance that there is an opening double-quote without a closing one, the possession might come in handy but truth be told writing it was purely accidental. So, no requirement but it wouldn't hurt to use it. As for the \h; if there's only ever going to be a single space character, use that. I don't see why using \h is any more "odd" than using \s, perhaps its use is less common but that's no reason not to use something. As for using NULL instead of 0 or -1 for the limit parameter (not count) that's just personal preference. NULL, 0 and -1 all end up as -1 eventually and I like to use NULL in place of "no value" so in this case using NULL is fine (in my opinion). Also, a general convention for "skipping" parameters to use later optional ones is to use NULL; as stated on the preg_split manual page "use null [for the limit parameter] to skip to the flags parameter".

You could swap around the array keys and values, like: $array = array( 'Dog Brown' => '1-2-3', 'Dog Black' => '1-2-3', 'Cat Brown' => '4-5-6', 'Bird Black' => '7-8-9' }; $result = 'No match'; if (isset($result[$search])) { $result = $result[$search]; } echo $result;

Here's one way (of many!): $words = preg_split('/\h+|"([^"]++)"/', $content, NULL, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY); var_dump($words); The logic being that we want to split words on whitespace or grab the phrases in quotes. That style of dual purpose (splitting yet also capturing) can take a while to get used to but it is very useful.

That's a character encoding issue unrelated to XPath. It's probably better to ask the question in a new thread.

One way would to be grab the table which wraps all of your required information, then use a couple of XPath queries looking for the specific details within that wrapping table. For example: $table = $xpath->query('//table[4]')->item(0); $code = $xpath->query("//td[starts-with(text(), 'Misco')]/following-sibling::td/b", $table)->item(0)->nodeValue; $man = rtrim($xpath->query("//td[.='Manufacturer:']/following-sibling::td/strong", $table)->item(0)->nodeValue); $part = rtrim($xpath->query("//td[.='Manufacturer Part No:']/following-sibling::td/strong", $table)->item(0)->nodeValue); var_dump($code, $man, $part);

There are lots of things that you could do to improve the execution time of the plugin, I'll touch on a couple but it might take a few major iterations to create something you're really happy with. Important point #1 is that each time you call the main function it re-opens-loads-parses-closes the synonyms file. Call the function 5 times, for 5 articles on a page, and it does lots of identical work 5 times. Ideally we would like to cut this down to only once (if at all, see later) per page execution. There are a number of different ways you could achieve this: 1. load and parse the file into memory once and keep that hanging around for all of the other function calls, e.g. using a static function variable; 2. change the dictionary into something easier to work with, e.g. into a PHP array that you can just include (or require_once into a static variable); 3. Doubtless there are other ways too. The next one is calling preg_replace many dozens of thousands of times. As with above, we need to whittle this down if possible. One way is to do what cags mentioned and grab the target word in whatever state of case it is and deal with the case elsewhere, e.g. in a callback. There's also optimising the regular expression itself. Currently, due to the arrangement of the lookahead, at every position in the article, every following non-greater-than symbol character is looked at, then the less-than-or-end alternation is checked, then potentially a whole heap of backtracking happens until less-than-or-end is met, then (and only then!) the engine moves on to check for the target word itself. That's a lot of overhead happening for each and every character in the article, even for non-matches. One quick fix would be to match the target word first, then later check if it is not within a HTML tag. Even with a callback, preg_replace_callback might be called once for each word in the synonyms list (for each article). You could experiment with using arrays for the pattern and/or subject arguments to see if combining the regular expressions and/or splitting up the article help at all. Also as cags mentioned, it would be far better to do the 'synonymization' once (when the article is published? or on some other event) than on each page load. This is a lot of work to be doing for each any every time the page is loaded. At the number of times they're being called, even functions like str_replace, strlen and explode might have a discernible effect on the running time of the function. If possible, it might be worth looking for other ways to achieve the same result: e.g. is strlen really needed (is there ever less then 3 characters on a line?)? You could replace the str_replace lines either by a single call to it or just using rtrim around the fgets call. This last paragraph though is likely more eeking out tiny changes compared to the big stuff above.

You can't require_once a list of files like that. Each file needs to be 'required' individually, e.g. require_once("microADRotator.php"); require_once("microBannerRotator.php");

Wishing everyone the happiest of New Years to all you Freaks. Lets hope this is a great year and an even better decade to come.

There are numerous points in your code which might not be as efficient as other methods. How intensive is "hugely intensive" and how slow is "very slowly", if you don't mind my asking? As for performing the regex more efficiently, there are a couple of factors. First is just the number of function calls (e.g. 68,000 times) — calling any function 68,000 times will take a while. Secondly, the regular expression itself could likely be much more optimised.

At least mine (I didn't test the others) worked with the brackets in the samples provided in this thread: so it should work at least a bit. Again, as with my last post, please give us more representative samples of the input that our regular expressions will need to work with, including ones that "work" and "don't work" at the moment.

One way (of many) would be: $newlastname = $row['name']; if (preg_match('/^[^,]+(?=,)/', $row['name'], $match)) { $newlastname = $match[0]; } If you're using PHP 5.3 then you could instead use strstr and even if not, basic string functions might be easier, cleaner, etc. in this case.

The "some reason" is probably that you have a wider range of input than you've cared to mention so far. Please give some examples of when the solution does not work, my bet would be the comma-separated-values-within-square-braces can be longer than a single character. P.S. Have you tried all of the other "solutions" or just nrg_alpha's?

Have you done: http://developer.yahoo.com/yslow/faq.html#faq_cdn

One quick way would be to use a regex replacement; I've no idea of your familiarity with regular expressions so the following might go over your head and be totally inappropriate (no point using code which is gobbledygook!). (Try this code) $subject = '[A][A][A][A][C][C][C]'; function callback($match) { return $match[1] . (strlen($match[0]) / strlen($match[1])); } echo preg_replace_callback('/(\[[^\]]+\])\1+/', 'callback', $subject);

Depending on who the code is written for, I use different conventions. For example, in the PHP manual we must adhere to PEAR's coding standard (which uses K&R style braces); other work/projects require the use of Allman style braces/indentation or sometimes a K&R variant (aka. One True Brace). As for which I like best, probably one of those mentioned above (there are lots of other bracing/indenting/layout styles around). [ot]@PugJr that's entirely the point.[/ot]

You could also use array_slice/current in such a manner. For example: (Try this code) $array = array('alpha', 'bravo', 'charlie', 'delta'); $last = current(array_slice($array, -1, 1)); $next_last = current(array_slice($array, -2, 1)); var_dump($last, $next_last);

Are you trying to get the file size before it's opened or whilst it's open, before it's written or after it's written, before it's closed or after it's closed? Or none of the above?

Well, I definitely don't fall into the psychic category so until (inevitably) told otherwise lets assume it's always ",head:" :-) (And when told otherwise, don't help but instead yell at the OP for being annoying!)

The contents of the folder will have special traversal "folders" called . and .. (for current and parent folders respectively) and also "hidden" files are commonly a prefixed with a dot. Take a look at the scandir manual page.

A little late to the game, I know, but why not peek ahead to check if the comma is a field delimiter or not? Like /,(?=head:)/ or /,(?=[a-z]+:)/i

Well $contents is the name of a file or folder within the directory. The part of the if which is substr($contents, 0, 1) != '.' is simply saying if the first character in $contents is not a dot/period. The '.' is just a PHP string containing a dot, nothing magical or special.

When developing, always turn up your error reporting (and be sure to have display_errors as on!) to the fullest extent. Then, the (first) problem would become apparent.