kicken

Option 3) stream_socket_client The bind address can be set using the context parameter. Create a context and set it's bindto option to the IP you want. $timeout = '5'; $params = array('socket' => array('bindto' => 'x.x.x.x')); $context = stream_context_create($params); $socket = stream_socket_client('tcp://remote.host:port', $errno, $errstr, $timeout, STREAM_CLIENT_CONNECT, $context);

You need to store their ID in the URL somewhere to make it unique. The name alone is not enough. For example: example.com/member/1234/johnsmith or example.com/member/1234-johnsmith When someone visits the URL you extract the ID and use that to locate the member. Just ignore the name part, it's there only for SEO / Users benefit.

Having a hard-coded reference to your configuration class isn't really any different than just sticking global $configuration at the top of each function that you need to access the configuration from. If you ever try and do some unit testing, you have to create a Configuration class to satisfy those references, rather than just inject some other mock class for example. If you ever port the code to a different project that uses a different configuration setup you'll probably have to find those references and change them.

No, the rule is set. Your child classes must come after your base classes. There is probably some internal implementation detail that currently allows for the one case to work (my guess would be something regarding auto-loading) however this is something that could change at any time and should never be relied upon.

public function profile_view($user_id = null) { $stmt = $this->_db->prepare('SELECT memberID,username,email,profile_pic,active FROM members WHERE memberID = :user_id AND active="YES"'); $params = array(':user_id' => $user_id); var_dump($params); $stmt->execute($params); $row = $stmt->fetch(PDO::FETCH_ASSOC); var_dump($row); if ($row){ $user_det = (object)array( 'username'=> $row['username'] ,'email'=>$row['email'] ,'profile_pic'=>$row['profile_pic'] ,'id'=> $row['memberID'] ,'active'=>$row['active'] ); return $user_det; } else { var_dump($stmt->errorInfo()); } } Since you only want one row, there is no need for the loop. Check the return value of the fetch call to be sure a row was actually found. I've added a few var_dumps at places that might be helpful in resolving your problem.

$_SERVER['REMOTE_ADDR'] contains the address of the client. Using the IP to make decisions is generally a poor idea though. What are you trying to accomplish exactly? What does script A and script B do?

That's up to you. First you have to decide what you want to happen. After you decide that, you write the appropriate logic to make that happen. For example Feb 29th + 1 Year. Should it roll back a day to Feb 28th, or forward a day to Mar 1st. Mysql's default behavior if you overflow a month is to roll it back to the last day of the month. So Feb 29th + 1 year would be Feb 28th. Jan 31st + 1 Month would be Feb 28th. If that policy is fine for you, then you don't need to do anything special for the calculation. The other thing to consider is if these are intended to recur several times, how are you going to handle that? For example, if you just replace the original due date with the new calculated date, you'll no longer be accurate for these end dates. Jan 31st + 1 month would end up making the new date Feb 28th. After that all your subsequent calculations would be based on the 28th. Again, if that policy is fine for you, there's nothing special that needs done. Otherwise you'll need to come up with a strategy to handle those cased and implement it.

Your code assumes that the query result can be converted to an integer. This is true in the case of the older mysql resource, but not with the newer mysqli objects. This integer is apparently used to save multiple result sets into the $this->row variable. You could fix the immediate error by just removing that cast and appending the result to the array rather than use an index. However the code using that class may depending on that functionality so removing it would break things in other ways. I happen to agree with Jacques1, just because something is old doesn't mean you need to start fiddling with it if it's still working. And if you are going to, don't just hack away at it randomly, re-work it with modern code, even if that means just re-writing it rather than patching it. Without knowing more about how that class is used by other code it's hard to say what kind of work would be necessary to get it properly converted to mysqli (or PDO). If the querying result indexing "feature" isn't used you could ignore it. If it is, you'll have to emulate it.

The equivalent of a c#'s byte[] type in PHP would just be a string. So just send your string, there is no need for the unpack call. socket_write($socket, $message); I would recommend you use the streams api rather than the socket extension. It is a newer and better supported api. It will also allow you to easily do SSL as well if you need it, which you probably do if your C# code is using SSL.

Unless the ranking will be changing per-request it'd probably be best just to store them into a table and join with it during the query. You could have a background task update the adjustments periodically and store them rather than calculate them on the fly on each request. If they do need to be calculated per-request then creating a temporary table and joining to it would probably be fine. Creating a temporary table is pretty much the same as creating a normal table, except you stick the word TEMPORARY in the query. See the CREATE TABLE manual page for details about temporary tables. Specify ENGINE=MEMORY when creating the table for the best performance. As far as performance goes, I'd look at how your adjustment calculations affect things before worrying about the temporary table and joining to it.

You could do this in the query with a CASE statement. SELECT recurring, due_date, CASE recurring WHEN 'weekly' THEN due_date + INTERVAL 7 DAY WHEN 'bi-weekly' THEN due_date + INTERVAL 14 DAY WHEN 'monthly' THEN due_date + INTERVAL 1 MONTH WHEN 'quarterly' THEN due_date + INTERVAL 3 MONTH WHEN 'half-yearly' THEN due_date + INTERVAL 6 MONTH WHEN 'yearly' THEN due_date + INTERVAL 1 YEAR END as next_due FROM table Note that you'll have to determine in what manner you want to handle dates that may not be valid for all intervals. For example if the due day were Feb. 29th and the interval was yearly, or Jan 31st and the interval was monthly. You can check mysql's default behavior in those instances and see if that is acceptable or if you want to do something different.

Use a CASE statement in your select query. SELECT CASE WHEN tblWJC.WJCStatusID < 2 THEN 'Pre Production' WHEN tblWJC.WJCStatusID < 2 THEN 'In Production' ...

If you're worried about proper design, then post your database design here (either as create table statements or a diagram) and explain what you're trying to accomplish. Then we'd be able to tell you if there are potential flaws in the way you're storing the data.

Considering we don't write and maintain IPB, no we're not going to try and fix it. It'll get fixed if and when IPB fixes it and someone here feels like upgrading to the release with the fix. I personally always run with the rich text editor disable and just manually type bbcode when I want it. Much easier and never had any problems.

See the & sign before the second and third parameters? That means the parameters are passed by reference and the function is able to modify their contents directly. This type of setup is often used if you need to return multiple values along with a success or failure indicator. socket_getpeername's return value indicates whether the function was successful at all or if some error condition occurred. If it's successful, then the two reference parameters contain the information you want.

Why? What is forcing you to upgrade? If this code is so important, there should be no reason why you're forced to do something which would potentially make it non functional. You've already been given a few. They do not have replacement functions, but they do have compatibility code that can be written (to a point).

When you say nothing do you mean literally nothing, or do you at least see the server and "Databases" folder under it? If you see the server and databases folder then you would just right-click on "Databases" and do "New Database..." If you don't see anything at all either you're not connected or you may have messed up the installation somehow in which case, remove it and try again and pay close attention.

Note that the recommended replacement is not always a simple "just use this instead" type of replacement. For example, ereg and split used an entirely different regex engine with different conventions compared to preg. You can't just pass in whatever regex was given to ereg into preg_match and call it a day. You'd have to parse the expression and convert it into a valid preg expression. In general PHP has not really removed much to day, rather just deprecated the functions. The few functions that have been removed are ones that probably nobody used anyway, such as the functions to obtain the logo GUIDs As far as I am aware, probably the only ones currently that are gone that an old script might used would be the session_is_registered/session_register/session_unregister functions. In all honesty, if you have to maintain a script that requires an older version of PHP, you just have to run an older version of PHP. Either fix the script, or don't upgrade.

What exactly are you trying to do as an experiment? There are some listed in the change log if you search. I've no idea what you hope to do though, it makes no sense to me.

That depends of course on what kind of value you expect for bob. If you expect a boolean value it wont work properly since false || true = true. A strict test against undefined is best for simple types. For objects using || is convenient.

Watch your language. There's no need for the swearing. ip2long converts an IP address from it's string representation (ie, 127.0.0.1) into a raw 32-bit (for ipv4) number (2130706433). If you want the readable format (127.0.0.1) then why are you calling this function at all? There's also no need to be calling socket_getpeername twice, once is plenty. It will populate the variable passed in the second parameter with the remote end's IP address.

Considering this topic is in the Javascript forum, the correct answer is no, you cannot. Javascript has no concept of default values for function parameters. What you have to do is check whether the parameter was defined and if not, set the default. function someFunction(bob){ if (bob === undefined){ bob = true; } //... }

Technically error_log('Hello')'s behavior would depend on what the error_log ini directive is. If in PHP.ini you setup error_log=/var/log/httpd/test/validation.log then the two calls should be equivalent, including the permissions problems. In general though people tend to not setup error_log to point to a specific file so it ends up going to the SAPI's default handler which is apaches error log in the case of mod_php.

Checking for HTTP_X_REQUESTED_WITH being set to xmlhttprequest is pretty standard. Most ajax libraries set this header for you for this reason.

Yes, because of: Unless you've changed that, PHP doesn't have execute permissions on that directory, hence the file is not accessible.