kicken

Your URL is probably wrong. Seems like you tried to mix PHP style and JS style concatenation there. As such, you're PHP script probably isn't getting the correct ID and just loading everything.

No, you can edit the php.ini directly, but that's not the preferred method. The preferred method, and what all the php-* packages from apt do, is generate a new file in the conf.d directory (technically, a symlink to a file in the mods-available directory). This allows the php.ini file to be easily updated if it needs to be by future package updates since it won't be full of customizations. Since you installed the cmark extension manually, you'd have to generate your own file to load it, such as echo extension=cmark.so | sudo tee /etc/php/8.1/cli/conf.d/cmark.ini Or, you can just load it in the php.ini directly like you've done. You were having issues with the module being loaded twice. The point was that you needed to check that there wasn't a file in the conf.d directory also loading the extension if you were going to load it via the php.ini file directly. You can load it in either the php.ini, or one of those extension files, not both. Not if there's only one. The point was to make sure you didn't have an old copy from your previous install attempt still laying around. So long as you only have the latest working one, then leave it there.

If you're going to load the extension via the php.ini file, you should only have one extension=cmark.so line, so remove all the duplicates. The way ubuntu is setup is to load extensions via those files, not via php.ini modifications. Since you were having an issue of the extension being loaded multiple times, I was thinking you might have a file there loading the extension in addition to your php.ini modification. It seems, instead you've just attempted to load the extension multiple times in your php.ini file. You might also want to check the files under /usr/lib/php/ and make sure you don't have any old cmark.so files from your previous attempt still there that might get loaded by mistake.

I don't think you successfully uninstalled the previous attempt. With ubuntu you generally do not enable/disable extensions by directly modifying the php.ini file. Extensions are managed through included .ini files in /etc/php/8.1/cli/conf.d. Remove any extension lines you added to /etc/php/8.1/cli/php.ini, then check in /etc/php/8.1/cli/conf.d for a file that loads cmark.

I can't tell for sure, but it seems like maybe you're using JavaScript to populate the select list after a new student/time is added. The problem I think is that you're re-populating all the select lists with your code. You have: $('.i').html(data); Which will find ALL elements with class i and replace their content. What you want to do instead is find only the newly added .i element and replace it's content, not any others. Something like this probably: $(".dynamicform_student").on("beforeInsert", function(e, item) { const $i = $(this).find('.i'); $.post("index.php?r=student/student-lists&id=' . '"+$("select#ascteacherreport-ascid").val(),function(data){ $i.html(data); }); }); In the beforeInsert callback, this should be the .dynamicform_student element that triggered the event, so use that to create a new jQuery instance and then find a child of it with class i.

I'm not sure what you're talking about with storing two copies of the image. None of my code does that, at worst the version with the hex dump stores one copy. The version without the hex dump doesn't store anything, as shown by the low memory usage above. The hex dump stuff was there purely as part of the example/demo to help see how the data is structured, of course it's not something you'd be putting into a final result so why complain about it? Maybe you think it's storing multiple copies because the functions read data into an array and return it, which then gets copied into another array, but that's not how PHP works. PHP uses something called copy-on-write, which means if you just assign a value to another variable then both variables refer to the same data in memory. The data is only copied if you attempt to change one of the variables values in some way. Since my code never modifies the contents of those array's after their initial creation, they are never duplicated and thus there's only one copy of them in memory. Of course, my code was never intended to be a full parser, just a small demo for your benefit to show how one goes about reading and parsing the binary data of a file. Since the file reference guide only showed details on the JFIF header, that's all I bothered to implement. It is enough of a demo that you should be able to extrapolate from it how to parse whatever other structures you want. Congrats, it's always nice when you can finally see something working.

That appears to be an unfixed compatibility issue in the extension.

I still don't understand your overall process really. If the count is less than 10, then this frame would just sit there displaying TADA, there's nothing in the posted code that would make it reload and check the count again. If you're just reloading the entire main page when they submit an answer, then I fail to see the point of the iframe. If the main page also checks if they have answered 10 questions and blocks access, then after they submit the 10th question the iframe would never get loaded in the first place so it can't actually do anything. The whole thing sounds like a mess that needs to be re-designed to me. Like, skip all the iframe junk and just have the page when loaded check if the user has answered all 10 questions and if so display a 'You've completed this already, do you want to start again?' type page and if they hit yes then do your DB reset.

Can you expand on what you mean by it freezes? Does it sit there trying to load but never does? Do you just get a blank page? When hearing something works by itself but not in a frame, my first guess would be an X-Frame-options restriction. You'd get an error in your browser's dev tools if that's the case.

When you issue a query it doesn't give you an HTML table of data as the result as that would be pretty useless. The data is stored in memory in some format that may or may not even resemble a table, and the result you get is an object that allows you to access that memory. There are plenty of other things you might want to do with that data besides display it in a HTML table. Maybe you want to put it into a table in a PDF, or use the data to generate emails, or just fill out specific parts of a page, or .... So it doesn't make sense for PHP to just auto-generate an HTML table out of a result set. If you want to display all that data as a HTML table, then you need to generate the appropriate HTML to create that table.

Most things are available via apt, just just need to know the package name. You can either use apt search or your favorite search engine to help find that. kicken@web1:~$ apt search libcmark Sorting... Done Full Text Search... Done libcmark-dev/focal 0.29.0-2 amd64 development files for CommonMark parsing and rendering library ... So try sudo apt install libcmark-dev and then try installing the PHP extension again.

Notice the highlighting error? You have an extra ' after your dbname parameter.

If you want to store a path to an image in the DB, just use a VARCHAR column with some resonable maximum length. If you have control over the images file names (ie, you're making them / receiving them as an upload) then you can choose a length and just stick to it. For uploaded files, I tend to use a VARCHAR(16) and generate a random name of that length for the file. If you don't control the name (say, you're just storing a URL to an external image) then choose a maximum length that should be fine and just validate that in your form when creating a record. Either that or us a text column if you want to allow crazy long URLs. I tend to use VARCHAR(2048) for arbitrary URLs.

Try sudo phpenmod mbstring intl Then restart the server.

You can just get the date prefix and look search for dates using like. $today = date('m/d/%'); $sql = 'select * from users where birthday like ?';

data_length and index_length are already in bytes, according to the documentation, which makes your query not really make any sense (why multiple a byte value by 1024?). Have your query just select the byte values, then format them into kb/mb/gb with PHP. You can find plenty of functions that will format a size value online. $mailbox = $link->query("SELECT data_length + index_length AS dbsize FROM information_schema.TABLES WHERE table_schema = '$db_name'"); $db_size = $mailbox->fetchColumn(); $db_size = formatBytes($db_size);

You should read through the PCRE section of the manual to get an idea of what the various things in the patterns do, and what is available to use when constructing patterns. Using an online regex debugger can help you as well by letting you easily try patterns and break them down into their components.

No, $name contains the Javascript code, which when later evaluated by the browser displays the value you typed in. Use you're browsers view-source command to see the code generated by your script.

You have your if structure's out of order. This is the structure you currently have: if ($_SERVER['REQUEST_METHOD'] === 'POST'){ //validate data if (empty($errors)){ //save file } } else { //Display errors } You are only trying to display the errors when it's a GET request, which won't be running any of the validations and thus never generate any errors. The code to display your errors should be the else branch of your empty($errors) check instead.

For parsing the HTML and extracting the data, look into DOMDocument. Load the document, use getElementsByTagName to find the rows by grabbing the tr tags. Then for each row, use getElementsByTagName to get the cells by grabbing the td tags. Use textContent on the cells to extract the values.

ppname doesn't come from $_POST. You defined it here: #file name with a random number so that similar dont get replaced $ppname = rand(1000,10000)."-".$_FILES["file2"]["name"];

You'd just do the same thing, but with the variable for your file name. $ppname = mysqli_real_escape_string($conn , $ppname); However, this is not really the way you should be handling this issue. Instead, you should be using prepared statements with bound parameters. $sql = " UPDATE users SET band2 = ?, audio1 = ? WHERE id = ? "; $stmt=mysqli_prepare($conn, $sql); $stmt->bind_param('ssi', $_POST['band2'], $ppname, $id); $stmt->execute();

If they are logged in, then presumably their ID would be stored within your session, so grab it out of $_SESSION when you need it.

You essential just need to do what I did in my parseSegmentData function. If you don't want to use a function, you can just inline it like the rest of your code, it's only two lines. function parseSegmentData($fp) : string{ //Markers indicate the start of a segment which is composed of <length><data> sections. //The length is two bytes and is the length of the entire segment including the two bytes //used to define the length. //Extract the length from the next two bytes. $dataLength = unpack('nlength', fread($fp, 2))['length']; //Read the remaining data using that length value. Subtract 2 because //$dataLength includes the two bytes we just read to obtain the length $data = fread($fp, $dataLength - 2); return $data; } After you've identified a marker, read two more bytes and use unpack to convert them into an integer value. Then you can either read, or fseek() forward, $length-2 bytes. Skipping past the image data is more complicated as there's no length value. You just need to read the data until you find another marker (excluding the reset markers). The original parseImageData function I posted here failed to skip the reset markers, but the updated code on my working example has that bug fixed. Storing the bytes read into $imageData is unnecessary if you don't want to do anything with the image data, so code your version without that.

You are getting the reset markers (and likely the other odd markers) because as I mentioned earlier. Each marker has associated data. Remember the general format? \xFF\x??<marker>\x????<length>\x??...<data> You need to read the two byte length that follows the marker, then skip over $length bytes. That $length bytes of data is arbitrary and may contain bytes that look like markers. That's where the embedded images are stored for example, so if you skipped over that data you'd stop finding those markers as well which would fix that pre-mature end-of-image marker problem.