salathe

<offtopic> IMO, the experts here are very respectful. Perhaps we have a different interpretation of who exactly are the experts. </offtopic>

I guess the next thing is, why do you include * multiple times in your character classes?

My quoted "file path" is still considered valid: http://codepad.viper-7.com/JhTjr3 P.S. Keep it up, iterative improvement is the name of the game with regex.

So the following is a happy file path? (I'm only teasing, but hopefully it proves a point) P.S. An example of the above "file path" being tested against the latest regex: http://codepad.viper-7.com/kGwbB2

There are two key issues with ^(C:\\)[[:print:]]$ The (C:\\) is not quite doing what you think. Echo out the $pattern variable and you will see the regex that is trying to be executed. It starts like ^(C:\) Notice how there is only one slash there? Regex understands \) as matching a literal right-parenthesis ()) character. Since there is then no matching right-parenthesis to pair up with the left-parenthesis immediately before C; the regex engine will complain at you (with "Compilation failed: missing )"). To properly match the C:\ that you want, you need to be mindful of how PHP strings interpret backslashes and how the regex engine does too. You want the resulting regex executed by the regex engine to be like (C:\\) but to write that in string-form in PHP you would need a string like '(C:\\\\)' — as requinix already pointed out (twice now). Next, the character class [[:print:]] only matches a single character. In order to cater for more than one character, a quantifier is needed. In this case you probably want + to say, "one or more printable characters". This is nice and short, but you could also specify a min/max number of characters rather than "one or more" by using the {x,y} style quantifier which matches between x and y consecutive occurrences of whatever is being quantified (in your case, the character class). In summary, something that might be more useful could look like: $pattern = '/^(C:\\\\)[[:print:]]+$/D'; P.S. You'll see I've added a D — see if you can figure out why.

It might be my imagination, but back in the day there was also more conversation on forums. Times have changed and it's almost exclusively Q&A now, where forums have been left in the dust by specialist Q&A-centric sites like StackOverflow and its siblings.

Nearly, but not quite. It sounds more like you want to use [[:print:]] [[:ascii:]] is the equivalent of [\x00-\x7F] (find these numbers under "Hx" on asciitable.com). As you will see, this includes characters that aren't available on a keyboard. A better end of the range would be \x7E, since \x7F is the "delete" character. Then, the character class would be the same as [[:print:]]. SupraCharger, does the "print" class cover the characters that you are interested in? I only ask because most keyboards have keys which provide other characters (for example, horizontal tab or the enter/return key) and many keyboards can have other non-ASCII characters too (for example, the euro symbol or accented characters). There's no reason why you can't extend the character class to include characters other than in [:print:].

It's always good to keep on top of the latest (stable) releases. P.S. The badges took a beating too, by the looks of things. They could do with some polishing up.

Yes, the mysql extension will definitely stop being bundled as part of PHP. The ball is currently rolling steadily in that direction: the community has been dissuading folks from using it for many years, the PHP manual introduced "soft-deprecation" of the mysql functions last year, and the upcoming PHP 5.5 will introduce actual deprecation. It will most likely be moved at some future point (maybe PHP 5.6) to PECL, should anyone decide they absolutely must keep on using the old extension.

I can't particularly care either way whether you're really "pro" or don't have the first clue about the subject, or wherever you lie on that scale. I only aim to point out that it's silly getting upset when someone calls you out on claiming to be "pro" when you're very clearly not anywhere near close. Hardly anyone here knows every little thing about PHP, and I doubt anyone knows every little thing about programming in general. Everyone here is learning, every day.

You're both right/wrong. Next. There's no reason why the "common" parts could not be versioned in one file, and the server/site/whatever-specific parts (which could probably also be versioned too!) could not be added to the file during the build/deploy phase.

That code will not give the error you are quoting. Please make sure that A) the error still appears, and B) you show us the actual code. It would be most helpful to be shown the full error text (and all errors, if there are more than one), and the full content of the file(s) containing the error(s). P.S. Jessica simply found it amusing that it you claim to be "pro" at PHP, at least given the list of proficiencies in your signature. At least, a list like that is commonly used to show the author's current level of knowledge in those areas. If your signature is not such a list then please forgive any comments made. If it is such a list, perhaps it needs some amendment.

It looks like you're just learning this stuff, so it might be useful to know how to add elements directly with SimpleXML, rather than using the DOM functions. Two available options are: $sxe->addChild("node2", "content2"); $sxe->node2 = "content2";

Cheers! P.S. There is no reason to iterate over the SimpleXMLIterator with for... foreach is an iterator's best friend.

You could use XMLReader's expand() method to get a DOM version of the node. Then use the DOMNode base-class's method getNodePath() to return its location path. Note that this will give different location paths than if you were to use SimpleXML/DOM, which load the entire document. The XMLReader -> DOM -> getNodePath will not include positional information (e.g. /example/something[3]), whereas (optionally, SimpleXML ->) DOM -> getNodePath will include it. Hopefully you can see why XMLReader won't know that positional information.

There's also the DatePeriod class whose purpose in life is to repeat an interval some number of times. new DatePeriod($d, $inc, 28, DatePeriod::EXCLUDE_START_DATE)

Let's switch right away!

What have you tried?

Good job, keep it up.

Just to set the record straight… The special "of" behaviour was introduced in PHP 5.3.0; earlier versions will not understand this statement and will return FALSE. Whilst "last Monday May 2013" may appear to work (in that it doesn't return FALSE), it does not get the last Monday in May 2013. As described in the manual [1], "Relative statements are always processed after non-relative statements." The non-relative statements are "May" and "2013", and "last Monday" (meaning previous Monday) is a relative statement. PHP processes that as: Set month to May (midnight on May 1st of the current year) Set year to 2013 (midnight on May 1st 2013) Adjust day to last (previous) Monday (midnight on Monday April 29th 2013). [1] http://php.net/datetime.formats.relative

Here, $page is an array containing some SimpleXMLElement objects (each <page> element with the chosen <id>). You then try to update the second object in the array (it starts counting up from zero), is that really what you wanted? I only ask because there is otherwise no hint that there might be more than one <page> with a given <id>. If there is only supposed to be one matching element, then you'll want to use [0] there instead. Now onto the real problem: you cannot directly modify a SimpleXMLElement object as you are trying to do. Modification only occurs using the property-style or array-style syntax: $element->… = 'something' or $element[…] = 'something'. Usually this is for modifying child elements or the element's attributes, respectively. However there is a trick to modify the element itself. SimpleXMLElement objects are also hidden collections of elements that can be referenced by number using the array-style syntax. Since the "collection" only has one element, then you can use [0]. This means changing the above line to become: $page[1][0] += 1; // or maybe $page[0][0] Disclaimer: This is a strange quirk of SimpleXML and don't be surprised if you look back at this code at some point (later today, tomorrow or in a year) and make this face... P.S. The DOM extension is often a nice alternative to SimpleXML's confusing magic.

Oh, really? http://codepad.viper-7.com/4JSphY

There is an error on this line... if ($item->id = $id) Can you spot it?

The folks of Londonshire also use those particular characters. The number_format() function is not locale-aware, but it's easy enough to find the decimal point and thousands separator characters should they be needed (and there are alternatives, like the Intl extension's NumberFormatter).

It looks like it is something even simpler than stripping the quotes from around the values. But first a brief interlude. Your file (when originally downloaded from the other website) has line endings marked by the Carriage Return character (CR). This is perfectly acceptable, but used far less commonly than its two more popular siblings Carriage Return + Line Feed (CRLF) and Line Feed (LF). Opening the file in Calc and saving it, changes the line endings from CR to whatever the OS you're running on uses (Calc used LF on my Mac, and CRLF on Windows). PHP likes files that use line endings that it expects (i.e, LF on *nix, CRLF on Windows). Removing the quotes also happened, but has no bearing on why you were seeing issues. Now for what to do. Turn the following lines: $handle = fopen("GeneratedList.csv", "r+"); ini_set('auto_detect_line_endings', true); into these lines: ini_set('auto_detect_line_endings', true); $handle = fopen("GeneratedList.csv", "r+"); See what I did there? Setting that INI option below the fopen() call is too late for it to become used when reading from the file handle. P.S. I should have paid attention earlier to where you were setting the INI option.