Jacques1

Hint: 0.5 hours are 30 minutes. What you want is an integer division.

DOMDocument can produce perfectly formatted markup. If you want the kind of formatting you have above with the spaces and unquoted attributes, I suggest you don't use that. The formatting is simply bad, and using a buggy self-made parser just to have bad formatting makes no sense.

This combination doesn't make any sense, because now you have all the bad parts: The inefficiency of Psycho's solution and the complexity of Sepodati's solution. Don't just blindly copy and paste code. Try to actually understand what it does. In this particular case, I'd go with Psycho's approach, because it's more straightforward.

Dude. What you currently have: an automatically sized anchor within a fixed-sized list entry. That gives you a small clickable area in a big box. What you need: a fixed-sized anchor within an automatically sized list entry. That gives you a big clickable box. How to achieve this: Move the CSS rules from the list entry to the anchor.

requinix just told you how to make it work. This is a simple cut-and-paste job. Oh, well, you need one extra line for display: block.

OK, now we at least know what you want. First off: You realize that there are dozens of well-tested HTML parsers out there, right? PHP itself has DOMDocument. The only reason for implementing your own would be if you're deeply interested in formal grammars and want to explore actual parsing techniques, not just put together a few regex hacks. Otherwise, just use what's already there. In any case, your approach makes no sense. The point of parsing is to build a tree structure where each element is represented by its own node object. When you change an attribute of an element, you only change this one object. The tree itself has nothing to do with attributes.

You should explain what you want to achieve, not how you think it can be achieved (because that part obviously didn't work out). Show us a concrete example (not a “MyClass” class doing “something”) where the kind of feature you're trying to implement actually makes sense. Because I can't think of any.

You shouldn't bind the API too closely to the implementation you happen to use at the moment. Chances are the implementation will change, and that shouldn't force you to change or reinterpret all URLs. /interfaces should represent all physical interfaces which you can list, filter etc. /interfaces/eth0 is a particular interface (not a configuration). Deleting it makes no sense. The configuration can either be an attribute of the interface or a subresource. If it's an attribute, you UPDATE /interfaces/eth0. A subresource makes sense if you want to support multiple configurations: /interfaces/eth0/configurations. Templates are a separate resource: /templates. Applying a template is just a special case of creating a configuration, so there should be no special URL for that. Make sure you fully understand the difference between PUT, POST and UPDATE: PUT creates a new resource under the specified URL. POST appends data to a resource or creates a subresource under a group resource. UPDATE changes the data of a resource.

The problem with strtotime() is that it accepts a wide range of formats, most of which you hardly expect from the user (like “+10 weeks” or “last Wednesday”). Merely counting the characters doesn't guarentee a specific format either. On top of that, a lot of the date functions and classes allow nonsense dates like “2010-02-31” and silently fix them at the risk of hiding errors. There should be exactly one well-defined format, and you should check it both syntactically (with a regex) and semantically (with something like checkdate()).

You're missing the point. I'm not talking about your syntax error. I'm giving you an approach for systematically avoiding errors and improving your code. It's great that you've fixed this one error. But there will be many, many other errors in the future. Of course you could just keep coming back and asking others to debug them for you, but I'm afraid that will be very frustrating for everybody after a while. Or you can do the smart thing and try to learn from the mistake, so that one day you will be able to fix things yourself.

I have never encountered any HTTP client in any language that doesn't understand methods. Classical HTML forms don't support all methods, but you can simply tunnel PUT and DELETE through POST requests. This is a common workaround.

Allowing GET requests to change data violates the HTTP protocol and is potentially harmful. I also fail to see how building a reinvention of HTTP on top of HTTP simpifies anything. If at all, it creates a lot of extra complexity and confusion. The HTTP protocol is very simple: One resource has one URL, and clients can interact with it using various methods. URL parameters, cookies and body parameters have clearly defined meanings. All HTTP clients already support this, and this is how they expect it to work. In your case, you need an entire set of URLs (which aren't actually resource locators), you completely ignore the method (which can break caching or, even worse, lead to unwanted caching), and you throw all parameters into one big bucket (which can lead to name collisions and breaks the parameter semantics). This sounds like a bad idea.

You need to stop treating missing parameters and empty parameters equally. There's a big difference between the two. The empty() function is generally a bad choice, because even the string "0" is considered to be “empty”. Use isset() to check for existence and === '' to check for emptiness. If both parameters are missing, you can interpret that as the initial request and simply display the search form. If exactly one parameter is missing, something is wrong. Either there was a problem with the form, or the user has sent an invalid request. You should display an error message. If both parameters exist, you check if they're valid dates. What you do with empty dates is up to you. You can either display an error message or interpret them as “infinite” limits.

That's not the kind of attitude we have here.

No. You – need – to – read.

The test_input() function is nonsense, and you should stay away from whatever tutorial you got it from. We already had a long discussion about similar code yesterday (appearently you guys all read the same tutorials). Leave the input alone. You can check it and reject the request, but do not alter the data. Escaping must happen in the output procedure, and you need to use the right function for the specific context (like htmlspecialchars() for simple HTML contexts). Your data validation doesn't make sense either. You're merely checking of the input contains any digit, backslash (what?) or hyphen, so the application will obviously accept all kinds of strings. A much better approach is to provide a datepicker and not let the user enter arbitrary text in the first place. Then you only have to double-check the input format of the datepicker.

The problem with code is that it needs to be reviewed and actively maintained, otherwise you quickly end up with poorly written, outdated or even dangerous material. You can see this on many PHP-related websites which still spread bad code from the early 2000s. Personally, I'm also no big fan of this snippet culture. Code examples are definitely useful in the context of an article or a tutorial, but when you merely post a bunch of functions, most people will just blindly copy and paste them without gaining any actual knowledge.

Bethrezen: You have fundamental misconceptions about security, and you don't seem to get the essence of what I'm telling you. If you actually want to improve your knowledge, then you need to think much more deeply about the problems I've pointed out. In a nutshell, this is what your current idea of security looks like: You get messy input, you run it through your semi-magical function which removes all the unwanted and evil parts (code etc.), and out comes a perfectly clean, harmless string which can you can safely include anywhere. This idea is certainly appealing, and it's propagated by hundreds of PHP tutorials. But it's hopelessly naive. It's not just ineffective but actually harmful. The real world doesn't work like this: What the user sends you is text. Text by itself doesn't do anything. It's neither “dangerous” nor “unclean”. If certain text triggers security vulnerabilities in your software, that's a defect of your software which you need to fix. Trying to shift the responsibility for this problem on the user by coming up with all kinds of silly input restrictions is fundamentally wrong. There was actually an online banking software which wouldn't even allow you to enter words like “select” or “update” (since those happen to be SQL keywords). Do you really believe this demonstrates their brilliant security concept? Or shouldn't you be worried that they cannot even handle a fucking English word? As I've already tried to explain to you, the meaning of input is dependent on the specific language context. The exact same string can have entirely different effects depending on where exactly you insert it. Your simplistic one-size-fits-all function is by definition unable to handle that, because a) it doesn't know the specific context in advance and b) it cannot react to context changes. HTML alone has dozens of different sub-contexts with different semantics. On top of that, you're dealing with mail headers which again have their own syntax rules. And if your software becomes bigger than a single script, you'll be faced with an entire zoo of languages like SQL, XML, shells etc. This is why escaping is an output concept. You apply it right before you insert the value, because only then do you know the actual context. Understanding this is crucial. When you apply the concepts I've explained to your specific case, you'll end up with something like this: If you want to validate certain fields like the e-mail address, you can do that, but this is not a security measure. It will not protect you from anything. It's a usability feature to help the user correct obvious mistakes. This also means you need to get rid of excessive restrictions. To handle the mail-related stuff, use a high-level library like PHPMailer. Do not try to assemble the headers yourself, because this will very likely go wrong. If you send a plaintext mail, you don't have to escape anything. If you want HTML mails, then you need to escape each inserted value for its specific context. A template engine like Twig can help you with that and will greatly improve the code, because you won't have that PHPHTML mixture any longer. For the love of god, strike this function from your memory. Forget that it exists. This function should never have been created, and you obviously don't even understand what it does. How on earth is “I <3 PHP” code? This is a heart emoticon. I – love – PHP. Are you telling me that writing this down is a malicious activity which I should no longer be allowed to do?

You do not create a vendor directory, nor should there be a composer.lock in it. The directory is created by Composer while it resolves the dependencies and places the libraries in that directory. You obviously haven't done that step. So once again: Which instructions are you following? Because they definitely aren't the official ones.

You haven't solved anything.

Because your markup is tag soup. It's not even syntactically valid, so the browser can only render it on a best-effort basis. Since the value attribute is never closed, it goes all the way to the next attribute of the next element, swallowing that element. Everything after that is of course nonsense, but the browser manages to recover from that to at least render the other options. Always validate your markup, learn to write proper HTML and HTML-escape all PHP values. Right now, this is a complete mess, and you should be more surprised that the browser displays anything at all.

This makes no sense. Once again: Start with a proper form. A real, actual, functional form with an action attribute and a submit button. Forget that JavaScript exists and concentrate on the HTML markup. Chances are you'll end up with something like this: <form id="a_meaningful_form_id" action="serv_reply7.php" method="post"> <input type="hidden" name="a_meaningful_field_name" value="<?= htmlspecialchars($row['mpn'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') ?>"> <input type="submit"> </form> Several things: You've switched from POST to GET, so I don't know what you want. GET is purely for fetching data, POST is for changing data. Choose the right one. You have way too many cryptic names like "mpn", "p_n" and "pn". Use meaningful names. Despite my warning, you didn't HTML-escape the input. You must escape every PHP value. This is absolutely crucial. Once you've fixed this, you should have a working form. Test it. When that's done, then we can talk about JavaScript. This part will be very simple, because making an Ajax request based on a form is pretty much a standard jQuery feature. $(function () { $('#a_meaningful_form_id').submit(function (event) { event.preventDefault(); $.ajax({ type: $(this).attr('method') || 'get', url: $(this).attr('action') || location, data: $(this).serialize(), success: function (data) { alert("submitted"); }, error: function (data) { console.log("error"); } }); }); });

This is just the last message in a whole block of errors, right? Well, yes, your code has problems. Not only do you have zero error checking. You actively suppress the error messages which could actually tell us what's going on. In other words, you've made it pretty much impossible to debug your problem. You need to fix that. Do not suppress errors (unless you absolutely know what you're doing). The "@" operator is evil. Secondly, do not assume that code will never fail. You've just been proven wrong. Everything fail. When you try to read a GIF file, that file may not exist, or it may not have the right permissions, or it may be invalid. You have to be prepared for that, thoroughly check every single return value and log every possible error.

You need to stop injecting PHP values into JavaScript context. This is a recipe for disaster. Write a real, actual form with a proper target and a hidden field for that "mpm" thingy (this must be HTML-escaped when you insert it). Then, in a separate JavaScript file, override the default submit action with your Ajax HTTP request. This is not only much more clear. It also allows users who don't have JavaScript enable to still submit the form. The first step is always to write proper HTML markup. JavaScript comes after that. By the way, a synchronous Ajax request doesn't make a lot of sense. The whole point of Ajax is to be asynchronous (and that's what the "A" stands for).

What are you trying to do? Or what are the installation instructions you're following? The error message indicates that you're trying to include PHPMailer through an existing Composer environment, but this environment either doesn't exist or is defective. Which one is it? Or did you just copy and paste the code without actually knowing what it does? Then you should instead read the instructions on how to use the PHPMailer autoloader.