requinix

Seems alright, but there are 5 versions of FullCalendar and I don't know which one you're using. Check the browser's error console for any messages, and use its request monitoring tools to make sure that your fetch-tours.php really is being called and returning the data you think it is.

$title = isset($row['name']); $start = isset($row['dep_date']); $end = isset($row['ret_date']); Are you sure that's what you want to do with those variables?

Data does not simply disappear. If you name those columns in the UPDATE then only those columns will be updated - unless you have some sort of other magic happening in the table, like triggers. And what's the deal with student_id? Why is it in the UPDATE but not the INSERT? Unrelated, hopefully: did you know that MySQL has a INSERT... SET syntax? INSERT INTO semakan_dokumen SET email = '$stdEmail', surat_tawarn = '$fileName', ic = '$fileName1', That looks a lot like the UPDATE syntax, doesn't it? If you build one string in PHP with all the column=value assignments then you could use it in both queries. (Don't forget that the UPDATE query cares about student_id in addition to the other columns.)

The server must be capable of decrypting the data on its own. Can't get around that. But you're going about this the wrong way. First, ask yourself what are you trying to protect against?

Here are some relevant facts: 1. max_execution_time has some nuances in exactly what counts towards the limit. For instance, on Linux systems it counts only the time PHP itself is working, and therefore will not count time for disk reads which are performed by the system. 2. The average hard drive can stream data at about 125 MB/s. An 8 GiB file would take about 8000/125 = 64 seconds to read in full. 3. PHP's memory usage is not a perfect correlation to the underlying source - especially given that md5_file() will be performing some amount of hashing work in addition to the literal file reads. 4. PHP claims memory in blocks. 8MB = some number of blocks taken * the memory used per block. Do you want to know the exact truth of what PHP is doing, or would you like to continue investigating to see if you can discover it for yourself?

Sounds like you've already given it a situation where it would have run out of memory and it did not...

Your code will disable the button that was clicked. Are there other buttons that also need to be disabled? All your screenshot shows is the Submit and Update buttons.

So for each of those columns, you want it to be that the column IS NULL OR the column = some value?

What is an sample of the HTML you're trying to locate? Some actual HTML. Make sure you're doing a View Source of the page and not looking at the rendered version through the browser's developer tools.

Looks like that part is dynamically generated. Going to be a real pain to use DOM to find it. But why bother? The only thing there is some static text and a link with a static URL.

Question: are there going to be people who are "members" of multiple towns? Not the sort of thing I would expect, but then again I can't tell what it means to be a "member" of a town.

Have you considered looking for an error message that might explain why you're getting a 500?

You'll need to use service workers.

You can do it on mobile the same way you can do it on the desktop: with AJAX polling or websockets. Polling is easier to implement but not instantaneous - which is probably fine for you.

Okay. What's the original code before you started making changes, and how do you know what folders are "from" a user?

1. What's the original code before you started making changes? 2. How do you know what folders are "from" a user?

One session cookie can cover all three apps, since they're all on the myserver domain. That requires whatever PHP setups are serving the three apps be all be able to access the same session files, and that all three should be running some shared code which is capable of handling the user account. Most likely, since they're all just different paths under the same domain, make sure the session cookie is set to the root path and not just one app and it should work. More complicated would be an OAuth setup, which would be mostly necessary if the sites were potentially being hosted on different websites and/or servers.

$_REQUEST is discouraged, not deprecated, due to the way that it may or may not contain certain values depending on php.ini settings. Best practice is to get the value specifically from the query string ($_GET) or submitted form data ($_POST). But unless you have a weird setup, $_REQUEST should contain both of $_GET and $_POST (if not more). If there is no "shortUrlDomain" key in it then that probably means there was no value being passed, so the first step should be looking at where the value is supposedly being passed to the PHP script.

Great. Code is a good first step. The next step is describing your problem: what are you trying to do, what do you expect to see, and what are you actually seeing?

This var li = $('<li class="pagination-link"></li>').html(item).attr('id', function(i) { return 'listing' + (i + 1); }); won't work because the li is only one element (at a time) so they all have i=0. Barand's code has a typo and should be var li = $('<li class="pagination-link"></li>').html(item).attr('id', index); which correctly does what the first code was attempting to do.

I can see that your list of menu buttons isn't dynamic and it should be, which will also fix that one bug and make sure it doesn't happen again. Otherwise I can't tell what you're asking about either.

What is "->save", exactly? Try telling me in as much detail as you possibly can what that line is supposed to do. Lots of detail. Like you had to explain it to someone who is new to programming and has very little understanding of how things work.

$data->save;

🏌️‍⛳

You know your application and framework (looks like Laravel) better than us so it's not like we can instantly tell you what table and/or column(s) you have to update. If there's a "last logged in" timestamp on the user table then update that. Otherwise...