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.

No. Only individual files specified in the .htaccess file. You could add an Apache handler that caused all images to be passed to the PHP engine, but using the mentioned method only allows for individual files to be treated in a certain way (in this case, as a PHP script).

A dynamic image is one that can be changed, for instance a single image that displays different text each time you view it. An animated GIF is not dynamic - although the frames may change to form the animation, the image is still in itself static. A dynamic image can be created in PHP via the imaging functions provided in various libraries.

This is only a very quick tutorial, meant to complement the dynamic signature tutorials that already exist here. It's nothing new, but it was just brought to my attention that not many people seem to be aware of this method. This does not cover the actual creation of dynamic signatures, per se - but rather a better 'trick' to allow you to use dynamic signatures on forums such as this one. I've noticed that most of the dynamic signature tutorials on this forum state that you must place a file index.php in a folder <filename>.png, in order to trick Invision Power Board (and other forums) into thinking that it is linking to an image - but when the user's browser attempts to access the folder image.png, it is redirected to the index.php script. However, this is very 'hackish', and in my opinion, not the best way to go about it if you have a choice. If your host runs Apache and it is configured to allow it, you can create a script with any extension - such as .gif, .png, .jpg, or whatever - and use a .htaccess file to cause the script to be passed to the PHP engine, and therefore treated as a script and not an image. This means there is no 'tricking' the forum into thinking that a folder is a script and causing access to be redirected to the script contained within the folder - the image is the actual script. So rather than having signature.png/index.php, you can simply have signature.png - and all the PHP code is contained within that file. In order to use this method, you simply need to add file handling instructions to a .htaccess file located in the same folder as your dynamic signature script. You can name the script whatever you like, but make sure it aligns with whatever type of image the script is creating and the Content-Type header it sends (which seems to be PNG for the majority of tutorials): <Files signature.png>ForceType application/x-httpd-php</Files> And that's all there is to it. No more relying on Apache's method of automatically redirecting access of a folder to a pre-defined directory index in order to use dynamic signatures in forums and other areas that only allow images with a recognised image extension to be linked to.

You can link to a PHP file as an image (eg. site.com/image.php), and the browser will treat it as an image provided the script sends it the correct header specifying the type of file it is - such as header('Content-Type: image/gif'). If your host supports it - which I belive Xisto does, although I may be wrong (I don't have hosting here) - you can force a certain file to be treated as an image by way of a .htaccess file: <Files image.gif>ForceType application/x-httpd-php</Files> Thus, the file image.gif is in actual fact a PHP script, even though it has a .gif extension. Placing the index.php script in a folder called 'image.extension' may work, and it is mentioned in most of the dynamic signature tutorials I've seen on Xisto, but it is a little 'hackish' and certainly not the way to go if you can avoid it.

An easier method is simply to have all the 'acceptable' values listed in the database along with your content, and after sanitizing the GET value, using it to retrieve the information. This way you can have greater control over your pages from whatever you use to manage your content. Quick example: $value = isset($_GET['value']) ? $_GET['value'] : 'index';$value = get_magic_quotes_gpc() ? stripslashes($value) : $value;$result = mysql_query('SELECT * FROM page_content WHERE page = \'' . mysql_real_escape_string($value) . '\''); (Note that stripslashes() is used just to avoid conflict with mysql_real_escape_string()).

Never, ever, ever, ever do this. Ever! Anyone with even the most basic of PHP knowledge could use this to break into your site and/or reveal sensitive information. Combined with the so-called null poison byte, files which would otherwise be protected such as .htpasswd could easily be revealed (file.php?gi=protected_directory/.htpasswd%00), or files executed that you don't want to be executed. You absolutely must always sanitize user input, no matter what it is or how insignificant or unabusable you think it may be - everything from GET values to a cookie's content and other header information has to be checked before being used.

It doesn't work like that. PHP is only server-side, and JavaScript is only client-side. As I said, the variables are going to have whatever value you assign them in the script. You can't assign them a value of '0', and then expect them to retain that value on later executions, because they won't. The only way you can do that is by storing the value somewhere, and recalling it later. If someone executes your script to add the values '2' and '3' together, the script isn't going to 'remember' that it used '2' on the next run, so the variable isn't going to have a default value of '2' or anything. I think that's what you're getting at, anyway.

I'm not quite sure what you're asking, but if you mean how do you reset the variables within PHP when the Reset button is pressed... the value is only going to be sent to the server when the user clicks 'Submit'. The Reset button is handled only on the client-side, so clicking it doesn't interact with the server at all. The variables are going to contain the value they were initially assigned (in this case, the integer value '0') each time the script is executed, and the values will not be 'remembered'. And no, the only way to handle button clicks (and most other client-side events outside of the standard markup) is via JavaScript. Most people have it enabled.

When you're just dealing with numeric values, you don't need to do any form of sanitization outside of is_numeric() - if the value is not numeric, then cancel. Additonally, unless you are passing the value to something outside of PHP, evaluating it as code, or treating it as a filename (as well as a few other exceptions), there isn't really a lot that can be manipulated by user input. The worst that could happen in this particular case is the operation failing, resulting in an error being displayed and revealing path information etc.darran, set the initial value of the input fields to '0' and the reset action should result in them reverting to this (ie. <input type="text" name="field" value="0">).

Just try adding some simple checking of each element: $rad1 = !empty($_POST['rad1']) ? $_POST['rad1'] : '';$_1stNumber = !empty($_POST['txt1stNumber']) ? $_POST['txt1stNumber'] : 0;$_2ndNumber = !empty($_POST['txt2ndNumber']) ? $_POST['txt2ndNumber'] : 0;if( $rad1 == 'Divide' ) { if( $_2ndNumber == 0 ) { echo('<font color="#FF0000">Cannot divide by 0.</font>'); $rad1 = ''; }}$result = "";if ($rad1 != null){

He has clarified, in his previous post. He wants scripts to be able to send a 404 Not Found message after processing the request.