Jacques1

Um, what? Your coder has run away, and now you think we should do the work for free while you appearently don't even know how the page should look like? Fo' shizzle. I can move your thread to the hire-a-programmer section. Maybe you'll find somebody who doesn't run away.

Since you aren't dealing with a proper data structure, I would not make any assumptions about details like the presence of a semicolon. One line (appearently) consists of an ISBN followed by additional information in parentheses: <?php const BOOK_REGEX = '~\\A(?<isbn>[\\d-]+)\\s*\([^)]+\)\s*\\z~'; $bookFile = fopen('/path/to/file', 'r'); $isbnCollection = []; $lineNumber = 1; $matches = null; while ($line = fgets($bookFile)) { if (!ctype_space($line)) { if (preg_match(BOOK_REGEX, trim($line), $matches)) { $isbnCollection[] = $matches['isbn']; } else { echo "Malformed line {$lineNumber}: ".htmlspecialchars($line, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8').'<br>'; } } $lineNumber++; } var_dump($isbnCollection); fclose($bookFile);

The benefit of using composer is that you get automatic dependency management. If you rely on a phpunit.phar file, you have to manually download it on every system and make sure it's the right version. To get started, you can read existing tests of (simple) GitHub projects. If you don't like the PHP-specific resources, you can also switch to Java unit tests which work very similar.

The string from your API and the string in your source code use two different encodings (I'm guessing ISO 8859-1 and UTF-. Your editor and your page are also using different encodings, so you get an interesting collection of encoding problems. To fix this, use UTF-8 everywhere, particularly in your API.

Where does this weird input come from? Why is there no proper data structure which separates the ISBN(?) from other information?

I have no idea what a “classified post” is, but if you want an actual countdown, you need JavaScript. For example: Make an Ajax request, use PHP to calculate the number of seconds until the next possible submission, then start a JavaScript timer which shows and counts down those seconds. There are thousands of example scripts.

You are in daylight savings time right now, so your request doesn't make much sense in terms of how the real world works. But if you want to invent your own personal timezone, that's of course technically possible: <?php date_default_timezone_set('Etc/GMT+4'); var_dump(date('H:i:s'));

Possibly. It's just odd that somebody would complain specifically about the DST bit rather than the time being off. Anyway, maybe the OP can clarify this.

Um, what? You're saying you get the correct time with EDT (UTC−04:00). Then you're saying you actually want EST (UTC−05:00). So which is it?

And why would your users have to wait one hour? What kind of application is this?

Have you considered debugging your code? Does the mobile detection work at all? Which branch is executed, and why does the redirect not happen? You know, basic var_dump() debugging.

How many cases are there in reality? You definitely don't want the admin to mess with the document encoding, so the charset attribute is out of the question. Setting arbitrary HTTP options also isn't recommended, so http-equiv is irrelevant as well. That leaves you with exactly two cases: <meta name="..." content="..."> (HTML) and <meta property="..." content="..."> (RDFa).

Avoiding raw HTML is also a matter of usability. I do know HTML, and I would still very much prefer a proper GUI with a combobox over having to manually write down tags, some of which I would first have to look up. Now imagine a layman struggling with a syntax error somewhere in a big block of markup.

Why would you ever redirect to the current URL? All that does is start an infinite loop. The layout of your URLs is also odd. So if there's an /m/ anywhere in the path, that's automatically a mobile URL? What if the “m” has an entirely different meaning? A far more sane approach would be to set up a mobile (sub)domain and do a simple check: A mobile device accessing the desktop domain is redirected to the mobile domain A desktop UA accessing the mobile domain is redirected to the desktop domain In every other case, nothing happens.

What exactly prevents you from storing the meta elements as key/value pairs rather than raw HTML? This will drastically reduce the risk of XSS vulnerabilities. In any case, allowing arbitrary meta elements is a risk, no matter how hard you try to blacklist dangerous combinations. There will always be a problem you haven't considered yet (for example: using a <meta charset> element to break HTML-escaping). Link elements are even worse, because now we're talking about external resources like stylesheets (which can be used for attacks).

That's the whole point I'm trying to make: Your query doesn't yield any rows. The reason is that you're literally searching for the username :theusername Leave out the quotes if you want to search with a placeholder: "SELECT * FROM UsersRegTable WHERE username LIKE :theusername"

You cannot count() a PDOStatement. The “1” you're seeing is a nonsense value which is returned by default when there's nothing to be counted. Simply fetch() from the statement and check if you get a row or false.

If you want to refresh the page without being prompted for a resubmission, look into the PRG pattern (POST, redirect, GET).

And that's exactly the question I have answered in my very first reply: To reuse code, you create an extra method and then call it in the methods that need the feature. You might want to reread this thread, because I get the impression you've missed pretty much all of it.

CONVERT TO

The fact that “£” is still ISO-8859-1 encoded means you have not fully converted your application to UTF-8 yet. Re-read my reply #15 and go through each of the four steps. We cannot do that for you.

You asked how to call a constructor in every method to perform an authentication check. I've told you this is wrong and offered a functionally equivalent but sane alternative. I have not addressed the question whether your idea is the right approach for Laravel. If you want Laravel-specific help, you're in the wrong forum. I can move your thread to the frameworks section.

I'm afraid this isn't the only issue. The malformed output you posted earlier indicates that there are other encoding-related problems. Make sure the database is configured for UTF-8. Note that the database itself, every table and each individual column can have their own encodings. Make sure the database connection is configured for UTF-8. Make sure the Content-Type HTTP header declares the document as UTF-8 text. Either let your webserver do that or set the header in PHP with the header() function. Get rid of the ENT_IGNORE flag. As the manual explicitly says, this is a security risk. Use ENT_SUBSTITUTE to deal with invalid encoding sequences. It's also time to switch to HTML5. The days of HTML 4.01 are over.

The usernames are on the blue bars. Your name is osherdo, my name is Jacques1. Nobody ever said that except you. According to the documentation, you either attach the authentication check to the route or the entire controller (by calling the middleware method once in the constructor). So it seems your assumption that you have to do the check per method is simply false.

One of the two columns doesn't have a FULLTEXT index. Go check that with phpmyadmin (or whatever tool you're using).