requinix

Is there a particular reason why it can't simply be a number? Maybe there are other alternatives available - for example, substr(md5($id), 0, 13) (the same length as a uniqid) for $id between 1 and 1000000 is unique, so unless you plan to have more than one million employees that would be an easy option.

Why are you generating the ID by yourself? Don't do that. Use auto_increment.

Ideally, the controller is in charge of shuffling data between the model and view, and has no knowledge of how the data is stored (model) or how it's presented externally (view). So it should gather together the information that the view will need, and the view should take that data and arrange it into whatever HTML format is necessary. The controller is probably a class and the view is probably a file, but neither of those are actual requirements.

You are executing that file twice, as in through two include()s or require()s. At least. Don't do that.

Is that actually what you did? If so then you outputted "data=$doc". Either output the value of $doc at those two locations, or post your real code.

Generally APIs work either (a) server-side with something like cURL or (b) client-side by using an external Javascript library which does the API calls and thus obeys the same-origin rule. If you were supposed to write your own Javascript code to interact directly with the Maps APIs then Google would have to set up CORS to allow that. Proxying is probably the best solution. Any reason you're trying to stop doing that?

It's just a form of URL rewriting. Every time someone requests the directory itself you redirect them somewhere else. Looks like RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ - [F]which will actually send a 403 Forbidden if they request something that is not a file (ie, is a directory or does not exist). IMO that's better than a redirect. If you really want to redirect then just change that RewriteRule accordingly, making sure it sends a permanent redirect (R=301) instead of the default temporary redirect. Oh, and that would go in a .htaccess within the first image folder: if your images go in /images/* then you'd put it in /images/.htaccess.

Where is $xpath coming from? Did you forget to create it?

So what you're saying is that var v = $("select[name='"+vt[i][0]+"']").val();is getting you the wrong value? Remember that vt[0] will be like "type" or "name" which means you're doing $("select[name='type']").val()

No reason why we couldn't do it... But before that we're considering what to do with the forum software itself. Like, should we upgrade, or switch to something else besides IPB? Or upgrade now and switch later?

I'm watching a TV show with a duration of 1 hour. When does it start and end?

It's not just a coding style issue. isset($_POST["button"]) and $_SERVER["REQUEST_METHOD"] == "POST" do two different things: one checks for the presence of a field/button in POSTed data, and the other checks simply that the request was sent using the POST method (which means it likely contains a request body). There's some overlap as to which is more appropriate for a given situation, but neither one nor the other is strictly "better". In the case of a form with only one action, you know logically that if the form was submitted then it is supposed to perform that one action. The presence of a button tells you that the form was submitted using that button, but technically speaking you don't need to require that the button was used. If the form was submitted via AJAX then the button is likely not present, yet the form should still be processed normally because you care that the form was submitted at all. In the case of a form with multiple actions, such as Save or Cancel (and you choose to handle Cancel as an action rather than implement it using, eg, a link back to the previous page), then obviously you need some way to determine which action was requested. Looking at the REQUEST_METHOD will not be enough for that, and named buttons are the easiest solution. You can still do the former as a sort of sanity check, but like I said before I believe $_POST is only filled for POST methods so the presence of a button automatically implies a POST action; missing both buttons means you can't tell what action to perform and you're free to do whatever you want (like redisplay the form). The REQUEST_METHOD matters a lot more with a RESTful API design. It's quite likely, and arguably it should be, that a particular URI will receive multiple actions determined according to the REQUEST_METHOD. For example, a POST to /user/1234 is a different action than a PUT to /user/1234 and most certainly different from a GET. Here there is no submit button, but the "multiple actions" thing still applies: the "page" can perform multiple actions and you determine which by looking at the REQUEST_METHOD, and simply testing for a $_POST field is not appropriate. That overlaps with regular webpages, where you have one serving both as the location of the form as well as the code that processes the form. If you don't look for a submit button then you definitely need to know whether you're supposed to display the form (GET) or process data (POST). Your "design style" argument raises a good point too: if you need to test for a field in $_POST then there's no need for an additional check of the REQUEST_METHOD. It goes towards reducing code complexity. if ($_SERVER["REQUEST_METHOD"] == "POST") { if (isset($_POST["save"])) { // ... } else if (isset($_POST["cancel"])) { // ... } else { // redisplay form } } else { // redisplay form } Given that "$_POST is only populated for POST requests", the code can be reduced to if (isset($_POST["save"]) /* which implies REQUEST_METHOD=POST */) { // ... } else if (isset($_POST["cancel"]) /* which implies REQUEST_METHOD=POST */) { // ... } else if ($_SERVER["REQUEST_METHOD"] == "POST") { // redisplay form } else { // redisplay form } and then to the obvious conclusion of if (isset($_POST["save"]) /* which implies REQUEST_METHOD=POST */) { // ... } else if (isset($_POST["cancel"]) /* which implies REQUEST_METHOD=POST */) { // ... } else { // redisplay form } Thus there is no need to test the REQUEST_METHOD.

"Should" is debatable. IIRC $_POST will only be filled for POST methods, so if the button is present then you know the form was POSTed. What I think he's getting at is that you can not check for buttons (which requires naming the button) and look for a POST method instead. It's also possible to AJAX a form without including a submit button, so testing the request method is immediately compatible with that.

A refresh alone will not make your site stop working. Too many people refreshing at once, that could be part of it: each refresh is just another request to the server, so if you figure there are 10 actual people visiting your site every minute then really it's effectively 20 (each person loads the page normally at first then it refreshes a minute later).

Okay, that makes things a little bit clearer, but... What's your code?

What? What result? Turn what red? Replace what text with HTML?

$value is never an array. It's always a SimpleXMLElement object. Even if the XML node does not have children. Try count()ing to see how many children the element has.

Oh, you put the form in the email? As HPierce said that's definitely not a portable solution, but I agree that it could be the cause of the problem. I also saw Content-Type mentioned somewhere as a potential source of the problem. Try removing that. But you really should get the form out of the email. Typically this means a link, probably styled as a button, going to a webpage with a real form. I definitely recommend that approach.

Is it the actual string "net err cache miss" and not like "net::ERR_CACHE_MISS"? And you say the rest of the process is working fine? As you've probably seen it's apparently an issue with Chrome, but one that should have been resolved in 2014 or so. What version of the browser is the phone using, and are there any updates for it?

The complex syntax in $url2 is more or less universally recommended.

Just an example. It just clicked with me what the code is doing and that it has to do with those point whatever things the two types and the composite/custom one stuff. Looking up the custom stuff probably involves a database hit, in which case there's no real point making the procedure more complicated just to make the PHP code non-recursive. So forget all that stuff I said.

You could build a key like "10,30" if you wanted. You're just using it to determine uniqueness while processing data - that's not quite the same as trying to generically represent a composite key in code. Myself, since there's only two pieces to the key I might go for nested arrays. array(10 => array(30 => array(/* 0, 3, N-1 */)))

Yeah, but do they have any reasons other than "because they can be misused"? Not really. Static variables, global variables, singletons... They can also be used badly, and sometimes they kinda lend themselves to it, but there are good uses for them too. Not if you consider the variable to be part of the "unit". And in this case, before and after the first non-recursive call to that method the static variable should be the same; now it's a bit harder to test that specific aspect, but testing the method as a whole (or other units which use that method) covers it too. The method is unaffected. The "static" in the term "static variable" (in this context) has nothing to do with the "static" that comes with static methods. It just means that the variable persists between calls to the function. Basically, yeah. Here's how the code looks the way I do it: $stack = array(array(/* initial state */)); while ($stack) { $state = array_shift($stack); // pop off $stack[0] // do whatever $state tells you to do // if you need to add more states to the stack then $stack = array_merge($array_of_new_states, $stack); // prepend }Having had my morning coffee* I realized this isn't hard to do this to implement a linear version of the recursive Fibonacci algorithm. $accum is equivalent to a return value from a recursive call and $stack represents the nth Fibonacci numbers that need to be calculated.You can see the recursive structure represented here: the check for $n is the base case and the merging into $stack is the recursion. function fibonacci($n) { $accum = 0; $stack = array($n); echo "stack = ", json_encode($stack), "\n"; while ($stack) { $n = array_shift($stack); if ($n <= 2) { $accum += 1; echo "accum = {$accum}\n"; } else { $stack = array_merge(array($n - 1, $n - 2), $stack); echo "stack = ", json_encode($stack), "\n"; } } echo "final result: accum = {$accum}\n"; } fibonacci(7); stack = [7] stack = [6,5] stack = [5,4,5] stack = [4,3,4,5] stack = [3,2,3,4,5] stack = [2,1,2,3,4,5] accum = 1 accum = 2 accum = 3 stack = [2,1,4,5] accum = 4 accum = 5 stack = [3,2,5] stack = [2,1,2,5] accum = 6 accum = 7 accum = 8 stack = [4,3] stack = [3,2,3] stack = [2,1,2,3] accum = 9 accum = 10 accum = 11 stack = [2,1] accum = 12 accum = 13 final result: accum = 13* Hot chocolate.

Why not? I would have mentioned it. As long as you manage its state and value correctly - eg, adding to it when going deeper and removing from it when returning - you should be fine. But see my fourth thing below. I wouldn't do it for a public or protected method, but for a private method that can only be called from within this class it's not that bad an option. Use defaults so the caller doesn't have to care. I wouldn't want to do that for myself: I don't like the idea of a class specifically designed to have only one (external) method. However if it turns out to be the most reasonable solution, considering things like clarity and maintainability, then... eh. Without me going through the code to confirm, it may be possible to implement this non-recursively. The basic approach to that is to use a loop with an array as a state stack: add state onto it for the next iteration to process, remove when finished. For example... I don't know, I'm blanking on a simple example of a situation where the average person uses recursion that could instead be implemented with a stack.

A form field will be sent even if it is not visible to the user. Because you have the inputs named "link" you will always receive something like link=hariciLink&link=black&link=or link=dahiliLink&link=black&link=Örnek:%20http://www.websayfam.comThe hariciLink value overwrites the dahiliLink value because it is later in the form. Easy solution: don't name everything "link". Very easy. Also a good idea. Otherwise you have to worry about enabling and disabling inputs so that only the right ones get submitted with the form. <script type="text/javascript"> $(document).ready(function(){ $('input[type="radio"]').click(function(){ if($(this).attr("value")=="hariciLink"){ $(".box").not(".hariciLink").hide(); $(".hariciLink").fadeIn(300); } if($(this).attr("value")=="dahiliLink"){ $(".box").not(".dahiliLink").hide(); $(".dahiliLink").fadeIn(300); } }); }); </script>That code is what you use to show and hide the different link inputs. To make it enable/disable you can <script type="text/javascript"> $(document).ready(function(){ $('input[type="radio"]').click(function(){ if($(this).attr("value")=="hariciLink"){ $(".box").not(".hariciLink").hide(); $(".box").not(".hariciLink").find(":input").prop("disabled", true); $(".hariciLink :input").prop("disabled", false); $(".hariciLink").fadeIn(300); } if($(this).attr("value")=="dahiliLink"){ $(".box").not(".dahiliLink").hide(); $(".box").not(".dahiliLink").find(":input").prop("disabled", true); $(".dahiliLink :input").prop("disabled", false); $(".dahiliLink").fadeIn(300); } }); }); </script>or simply <script type="text/javascript"> $(document).ready(function(){ $('input[type="radio"]').click(function(){ $(".box").not("." + this.value) .hide() .find(":input").prop("disabled", true) ; $("." + this.value + " :input").prop("disabled", false) $("." + this.value).fadeIn(300); }); }); </script>Keep in mind that enabling/disabling the inputs comes with a visual change (stuff turns gray) so you should enable inputs before showing them and disable inputs after hiding them; .hide() is instant but if you changed to .fadeOut() then you'd have to disable after the fade out animation finished.