Spectre

I would use a structured database system for a CMS rather than flatfiles, such as MySQL (which is available via Xisto). In my opinion, flatfiles are useful for storing data where a database or even just a single table in a database is a bit of 'overkill' - in that the data you are storing is so small or insignificant that it isn't worth interfacing with a database engine (which is remarkably easy with MySQL in PHP anyway). Otherwise, I would recommend a database better suited for dealing with larger amounts of dynamic data.

This has nothing to do with cPanel or with linking. And he did post his code.I've never encountered this problem as such, electron, but when I did a little experimenting with it I got some interesting results. Some of the time it would work fine for me and do exactly what it was supposed to - but other times there was some unusual behavior by the browser, including displaying the incorrect URL in the address box, displaying the correct URL but without the fragment, and displaying the fragment but not scrolling to it. As you said it works fine in Opera and FireFox, so perhaps it's connected to a bug in IE7 that hasn't been ironed out yet?

It is true that variables cannot start with a number, but $1 is not actually a variable; it is simply a backreference for the PCRE functions. The reason, I would imagine, that it wasn't working when you tried to pass it directly to the img() function is because you weren't enclosing it in quotes - eg. img($1) should not work, img("$1") should. Because $1 is not a variable, and because even if it were it is not being declared on a global scope, the img() function has absolutely no access to it at all - so thus by telling the function to deal with '$1', it is dealing with the literal string '$1'. Now, on to what's wrong with your regular expression. Firstly, the 'e' pattern modifier needs to be included when you want any evaluation of code to take place - so for instance '/\[b\](.*?)\[\/b\]/is' should be '/\[b\](.*?)\[\/b\]/ise'. Secondly, the replacements need to be strings - what you have right now are direct references to the functions themselves, meaning that as soon as you create that array the functions are being called, not when preg_replace() is used. So just say the img() function returned 'xyz', then that item in the $main_replace array would have the value of 'xyz'. So what the replacement array should be is: (note that I have seperated the lines just for clarity - you don't have to do this) $main_replace=array('<strong>$1</strong>','<em>$1</em>','<u>$1</u>','img("$1")','urln()','url()'); I don't know what, if any, variables are supposed to be passed to the url() and urln() functions, so they're empty. The reason it needs to be a string is because it is code that is supposed to be evaluated when, and ONLY when, that particular item is being replaced in the subject - so by calling the functions during the creation of the array, you are effectively defeating the purpose of the script. Hope that helps. Feel free to ask any questions or queries I didn't clear up. Oh, and peroim, the reason there are so many slashes (/) in the pattern is because it is the delimiting character for the patterns, as well as used in the closing tags for bbCode. The reason for so many backslashes (\) is because this is how you 'escape' a character - ie. if a character performs a certain function but you just want that actual character to be displayed or used rather than the special function it may otherwise reference, you escape it. For instance, in the PCRE functions, an opening square bracket specifies the start of a character class, and a closing square bracket the end - so if you want to process an actual square bracket, you need to escape it.

It has little to do with the algorithm used to determine the PageRank. What, at least far as I can gather, farsiscript wants is to simply retrieve the PageRank for a given from Google's server via the API.Unfortunately it isn't possible to do it this way. Google does not provide the PageRank through their API service. However, what you can do is calculate the checksum for the URL and send a request to Google's server in much the same way the toolbar does, which will then return the PageRank. There is one script in particular which is in the open domain, and shows you exactly how to do it. Just have a look around Google (the search engine, not on the actual Google website) and you'll find it.

First and foremost, always sanitize user-provided data. Search this forum for many a thread in which it has been discussed.Anyway, including the file containing that code should assign it to the respective variables. Included files are evaluated within the same scope as from where the include() function was called, meaning that you should have access to the variables immediately after including them. Functions, classes, and global variables are, of course, declared on a global scope no matter where they come from.

Of course you can! All you need is to find something unique about how the name is displayed - such as a certain tag being used - and the same for the picture. And then grab the webpage and parse it for those things. Both of which are practically handed to you: if( preg_match('#<span class="nametext">(.[^<]*)</span>#', $webpage_data, $name_matches) &&preg_match('#href="http://viewmorepics\.myspace\.com/index\.cfm\?fuseaction=user\.viewPicture&friendID=[0-9]*"><img src="(.[^"]*)"#', $webpage_data, $image_matches) ) { echo 'Name: <strong>' . $name_matches[1] . '</strong><br>' . "\n"; echo 'Image: <a href="' . $image_matches[1] . '">' . $image_matches[1] . '</a>';}

You don't really 'code in WAP', as such - WML is just the markup language (based on XML). You can use PHP or any other scripting language to spit out your dynamic WML code just as you would with HTML pages.

A well-written regular expression can match almost anything you through at it, particularly if it follows a certain structure - ie. HTML. What's an example of what you're trying to match, electron?

I have no idea what IPB does now, as I have not looked at any source code for it for quite a long time. Using a 'salt' is indeed a good idea, I'm not contesting that at all - I'm just saying that it still isn't completely safe.An old IPB version (I don't remember which were affected by it, but it's long been resolved - although similar problems seem to pop up all the time in various large-scale PHP applications) had a bug that allowed arbitrary SQL to be injected into the URL when quoting a post, if memory serves correct. So basically any data could be retrieved from the database, including the salt and the password, allowing the hashing process to be recreated by the attacker and the result then compared.My point basically is that if the method used to create the hash is known (eg. the data hashed and in what order), and the data used therein can be 'found', then the password can still be broken, salt or no salt. It may take time, but brute-forcing any one-way encrypted password does.

Well... you could do all that. Or: $string = preg_replace('#\[\[(.[^\]]*)\]\]#e', 'str_replace(" ","_","$1");', $string);

What exactly are you trying to output, and what are you trying to view it in? A web browser simply ignores newlines for formatting in an HTML document, generally treating them simply as a space. Try setting the Content-Type header to text/plain or using the preformatted tag (<pre>), or just add a '<br>' to your string.

Using a salt is certainly a good idea, but it not 100% secure. Even combining details as mentioned by Amezis isn't going to absolutely guarantee against the password being broken. In order for a password to work, you are obviously going to need to re-hash it from plaintext at some point in order to compare it against the already hashed password stored in the database - and if someone manages to obtain the exact code you are using to do this, re-creating the hash isn't going to be overly difficult. In Amezis' example, for instance, the attacker would simply need to obtain all the details that are being combined to create the hash - which they would presumably have if they were sniffing around your database to get the final hash in the first place - and then combine the applicable data with possible password combinations and run it through a dictionary cracker. It might be slightly more difficult, but it's certainly possible. IPB, for example, uses (or at least it used to use) a simple 4-character password salt which was hashed, and that hash was then concatenated with the plaintext password and hashed again, and the final value was stored in the database as the user's password. But all that had to be retrieved was the salt and the hash, and this process could very easily be repeated by anyone in order to eventually uncover the password.

Wow, this thread is certainly old.farsiscript, what are you asking exactly? The functions are obviously custom, so they aren't going to be on PHP.net (or in many other locations)... you'll just have to get information on them by looking at the source code above.

You would probably be better of splitting the post into an array with any non-alphanumeric character acting as a delimter, and using the number of items in the resulting array as the number of words. You may want to exclude words under a certain length as well (eg. anything less than 3 characters), possibly even run it by a dictionary file to make sure it isn't just gibberish. It's all possible and not particularly difficult, thanks to the beauty of regular expressions. Although I've spoken to Opaque about it in the past, I'm not sure whether or not the credit system here supports the re-calculation and deduction/addition of credits when a post is edited or deleted etc., but such functionality would certainly be nice.