requinix

Help for what? I told you not to run it from the command line, which you're still doing, but now you've posted part of your kernel log which I can only assume you're doing for a reason that I can't figure out.

Can you decouple the storage mechanism from the chart? Entirely? The general chart service would lookup the basic chart information, determine the data source, and inject that into the chart.

RemoteChart sounds like it's more of a data thing than a chart thing. Sounds like you need to abstract out the data retrieval/storage process. Probably specialized for the way charts will use it, but more or less separate from the actual chart business.

"Service" is probably a more accurate term. It may be functioning like a controller in that it has various actions called for requests, but it isn't directly interacting with the request or response so it's not quite entirely a controller. You're talking about single-responsibility with the chart creation bit? You're still observing it: the single responsibility of creating charts is in one central location. Your method seems more or less right: single place to look up chart data, chart identifier maps into a class through a factory, class handles the precise work of the various operations. Chart types are not dynamically created (eg, no user-defined types) so hardcoding identifiers and class names is acceptable.

Have you seen /etc/fstab?

Done.

The problem isn't that you have to intval() things. The problem is that $var1 and/or $var2 are not proper numeric values. You need to figure out why that might be the case, then probably add or edit input validation so that the non-numeric values are not being allowed.

Don't start it from the command line.

The AJAX request failed. Use your browser's developer tools to see what happened with it.

Use mt_rand() to generate a random number.

That's a new warning for PHP 7.3. Your composer is 1.4.2, current is 1.8.5.

Either you use it everywhere or you don't use it at all. I'm in the latter camp: I like the automatic conversions, and I'm already aware of and careful with value types. I would probably opt-in if I could do it globally, but there were good reasons not to support that and to only make it per-file.

According to Andrea (the original author of the scalar type hints RFC where strict_types came from), Shrug.

No, there is no such function.

As with most things in Linux, you install one program for the data and another program for a graphical utility. Try install psensor.

You probably didn't see that I edited your first, and now second, post: please use the Code <> button when posting code. You can't simply change the value in your <option> and expect it to work. If you want to support multiple values then you have to have code that supports multiple values. And this // check vars if(!is_numeric($query_city_id)) { die('Wrong city id'); } $query_city_id = (int)$query_city_id; and this $query = "SELECT city_name, state FROM cities WHERE city_id = :query_city_id"; $stmt = $conn->prepare ($query); $stmt->bindValue(':query_city_id', $query_city_id); do not. Decide whether you want "3,1" or "3;1" or "3 1" or whatever, then adjust the code so it can support one or more city IDs at a time.

using 3;1 or 3,1 could work if your code knew that it had to handle those. But I don't see where that code is...

opcache is for code, not data. Don't serialize: whatever you use to cache will serialize for you. A real memory cache like memcached or redis would be best. Can you?

How do you know how many points a user has?

No. The backslashes are optional but okay. It does not matter if they are there. Do not try to manipulate the JSON string like that.

Yes. PUT should be the entire body, PATCH should be whatever the changes are, and POST can sorta be either. So if you want to support a generic API for updating specific properties, use PATCH. PATCH /some/resource/123 HTTP/1.1 Content-Type: application/json {"option":{"plotOptions":{"solidgauge":{"dataLabels":{"enabled":true}}}}} Unless you think a sort of "enable/disable chart label" API would make more sense, along the lines of /toggle/label/name/state: POST /some/resource/123/toggle/label/solidgauge/enabled HTTP/1.1

Can't say I agree with that approach. It's too weird. Stick with the standard: the data in the request body. If, however, modifying one or three specific properties is a common use case then that suggests your API should support it with a specific operation.

Code seems fine, so that means the problem is that your query is returning duplicates. You've got a few joins in there, and you're using menu_item_id in multiple places which is suspicious. What's the source data and what results are you getting?

Is that what you want it to do, or not? The first lien line that sets the cookie is probably wrong, and the function isn't being called. You'd check for the cookie before letting the user click, and then also check the cookie in your PHP in case the user got around the Javascript block and recorded and uploaded anyways.

It should be either [{"name": "description", "value": "Some new description"}, ...] or {"description": "Some new description", ...} The second one tends to be much nicer to work with.