requinix

Use usort.

Stop throwing code at it with the hope that everything will start working and instead spend a minute thinking about what it is you're doing. It's a far more efficient method for solving problems. You've decided that $_POST has the page number of the results you want, and you put that value into $page. If you want to change page numbers then you need to include in the form data a new value for "page". The two buttons for previous and next are the things that the user will interact with, and they can each contain whatever new value it takes to make their actions happen. The previous button should use the previous page number and the next button should use the next page number - that would be $page-1 and $page+1 respectively, right? So you need to put the $page-1 and $page+1 numbers into the two buttons' values. We can worry about accidentally browsing to page 0 after that.

#i dont know how to increment and decrement inside the value echo "<button type='submit' name= 'page' value = '' class='btn btn-primary'>PREV</button>"; echo "<button type='submit' name= 'page' value = '' class='btn btn-primary'>NEXT</button>"; You might be overthinking this. It's true that you can't change the $page variable inside the string, which isn't exactly what you should be doing anyways, but you can do things outside the string. See what you can come up with along those lines. Also don't forget that you still need the two if checks you had before for when the $page is >1 or <the page count.

By policy we don't delete accounts, except to comply with laws like GDPR. If you don't want to use your account then you can simply not use your account.

Sorry but it is documented. Like strtotime, it will assume the input is a valid date/time string and try its best to make the most of it, and there are a bunch of different things that are supported. https://www.php.net/manual/en/datetime.formats.php

If you have further questions, please reply in this thread instead of reaching out over private message. <?php if (isset($_GET['page']) { $page = $_GET['page']; } else { $page = 1; } ?> $_GET is only used for values that go into the URL. They're easy to spot. Your form is using the POST method (which I would say is correct) so all values send that way must be accessed through $_POST. Try fixing that. If it's still not working then post (not link, please) the full code you have now with a detailed description of what you expected it to do and what it's actually doing instead.

The concept is called "pagination". For most people that has to do with database queries, but with your API calls it's still very similar in execution. You need to get the desired page number from the form; if you want Prev and Next buttons then you could include the page number in the form and know which button means -1 or +1, but easier would be to make the buttons have the actual page number as their values. Processing the form to get the page number has to happen before you use the API, of course. Your $page > 1 and $page < $result->pages checks are good for deciding whether to show the Prev and Next buttons, but since you need the page number before you use the API, you can't use the results of that API call to decide what to do. My suggestion is: 1. Get the $page from the form data (if it is >=1) or use 1 if there wasn't a valid number given 2. Call the API with the page number 3. Show the results like normal 4. In the form, if $page > 1 then show the Prev button, and if $page < number of pages then show the Next button 5. For the two buttons, give them a name of "page" and a value of $page - 1/$page + 1 appropriately: when someone clicks either button then that will submit a "page" in the form data for your code to use

Or it could be Apache couldn't log anything useful there because the client did not send a request in a timely manner - which is exactly what 408 means. Ignore that line, possibly by a regex or something, or ignore the warning from AWStats itself.

For what purpose?

Have you checked your server error logs yet?

You'll need a local environment for testing that is identical to the live environment. If it's running on "Linux", which is far more capable than you seem to think it is, then that's what you should have too. Learn the codebase inside and out, then check the PHP migration guides for 5.3 -> 5.4 -> 5.5 -> 5.6 -> 7.0 -> 7.1 -> 7.2 -> 7.3 -> 8.0, since that's where you're starting and where you're going. There have been a lot of changes over the few years and you're lagging behind by a lot. Decide what is obviously relevant and address it now. Make sure that your PHP reports everything wrong. E_ALL is not everything but the things you should commonly care about. Set error_reporting to -1 and make sure nothing reverts that, then double-check you have errors being logged as they need to be. Deploy the application locally and see what happens. However long it took you to get to this point, take at least that much more time with testing.

Two words: browser detection. As in using IE's conditional tags.

The setAccessible method. Not really. I'm a proponent of simple when it makes sense, but simple shouldn't be the goal.

Yes, it's possible, but you're getting to the point where you're abusing reflection so don't. If making properties public is not acceptable then use methods. The problem isn't the attributes - it's the properties. PHP doesn't have visibility on property reads/writes, so unless you want to switch to an immutable design with readonly properties... Here's the thought process: 1. Properties are nice, but you need the values from them. Don't want to make them public, shouldn't use reflection (IMO) to bypass visibility. 2. So you can't get the data from the properties. What other mechanisms are available? 3. Get the data from the methods. Dumb little getter methods with no logic. 4. How to get the "ranked list" data? At this point your answer is attributes. Not unreasonable, but you have to go through reflection and that's a red flag. 5. Mark the methods with attributes to discover them. 6. Still need to get "names" from them, and the methods will be "getName". So you have to unmangle those. My answer is a regular, everyday interface method. 5. Check that the class implements the proper interface. 6. Call the particular method in the interface that returns a set of keys (names) and values (RankedListInterfaces).

Moving the logic to a "getProperty" sweeps the problem under the rug: it's still there, not just as visible. I think what I'm seeing here that draws my attention most is using properties for half of the work and getter methods for the other half. Pick one: properties (list properties, check attribute, get value) or methods (interface method to list properties with capabilities and possibly getter closures).

I don't care for it because I don't like dynamic getters as a whole, but the design is widespread enough that I'm not going to protest too loudly. A basic thing like validating an attribute against a property should be done by PHP itself, but since it isn't, If you're looking for advice there, have RankedListAttribute do its own validation: add an interface (or not) and method for performing validation given a ReflectionProperty, then use your ReflectionAttribute to newInstance() and call it.

Reflection, list of properties, list of attributes given that there is no "hasAttribute"... yeah, that's about right. You could streamline the attribute search with a quick array_filter instead of a foreach: $hasAttr = array_filter($propReflect->getAttributes(), fn($attr) => $attr->getName() === RankedListAttribute::class);

I assume you've already searched your code for "MainContinueButton" to see if something added a handler to that specific button? You should know if it does AJAX by monitoring the part of the developer tools that shows you network requests and seeing that a request gets made. If Firefox's is anything like Chrome's then it can also tell you where the request originated from in code. For breakpoints, I don't know Firefox or what it can do. It should be possible to break on any newly running Javascript code, but it's easy for things like mouse movements to hit that too. Meanwhile Chrome's tools can list the event listeners registered on elements.

Set a Javascript breakpoint to stop when that button is clicked, then see what the handling code belongs to.

Are you using PHP 7 or 8? You should go with 8.0 because it has a number of nice changes from 7.x.

Depends on how do you want the site to remember - as in what mechanism saves the data. Because it has to be saved somewhere. For example, there's a session for saving information that you want to use on the rest of the site. And there's cookies for saving information on whatever specific device the user has at that moment. And there's databases for saving virtually anything for any reason. So for you to decide where you store it, you'll first have to decide why you want to.

The answer to that is most definitely We have absolutely no idea how your website works so we don't have the slightest chance of being able to look at that little bit of code you posted and give you useful answers for how to do things like query your database or add content to a webpage. Websites just aren't that simple. Who set up this site? Can you get them to do the work?

The most obvious thing I can see is that you're using a relative path for the images. Don't.

Rather than guess at what could be wrong. try to get some concrete answers. Such as why it would "redirect" to error.php. Under what circumstances does that happen? Upgrading PHP from 5.6 to 7.3 is a big jump. Did anyone do any testing before making the switch? Are there any PHP error logs available to look at?

It "stops working" doesn't actually mean anything. What does it do? What do you expect it to do? And post all of your code - not just some partial jsfiddle with a couple bits that don't actually match what your real code is.