requinix

Then you probably have a UTF-8 BOM at the beginning of the file. Open your normal editor and make sure it is not saving your files with a BOM. You may have to re-save all your PHP files once that's disabled.

Yeah, unless there is a particular need for that 1/2, 1/3, 1/4, 1/5 list then it really should be an array containing one entry for 1, that itself has another array of 2-5. array( "text1" => array( "text2", "text3", "text4", "text5" ) ) or array( array( "name" => "text1", "items" => array( array( "name" => "text2", "items" => array() ), array( "name" => "text3", "items" => array() ), array( "name" => "text4", "items" => array() ), array( "name" => "text5", "items" => array() ) ) ) ) Also your HTML is incorrect: the UL needs to be within the parent LI. Outside it is invalid. Keep in mind that ->find() will find all children, so ->find(a) on the text1 LI will find all five links. A better approach would be to find the A from the LIs set of immediate children, then from there go recursively into the immediate child UL if any.

That is the part of the message that matters. What is the first few lines of your index.php?

Working with those numbers as a string is proving to be a pain, isn't it? Then don't work with them as a string. Use an array, for both the input as well as the stored numbers. You can display them as a hyphenated string, but internally keep them as an array. explode() and implode() can help you convert between the two forms. Then the problem is how to take an array of five numbers and check against other arrays of five numbers to find what they have in common. Fortunately there's a function for that.

If you used actual NULLs and not 0000-00-00 dates then you wouldn't have to care about them. It's also better from a purist standpoint as a lack of data is what NULL is supposed to mean. SELECT * FROM Prospects WHERE UserID = ? AND FollowUpDate < ? Because comparing NULL with anything fails so those rows won't be matched.

Take a look at the code where you fetch the verse from the database. if ($result->num_rows > 0) { // output data of each row while($row = $result->fetch_assoc()) ; //$conn->close(); } Here's the thing: $row is only useful inside the body of the while loop, so... where is the body of the while loop?

You could do it with PHP, but the more you learn and advance with web development the more you're going to need to know Javascript and understand things like AJAX. One step at a time. Get the rest of your idea in place, the stuff you already know how to handle, then when you get to the trophies you can think about how to use the opportunity to expand your skillset.

You should not be sending emails as "From:" the user's email address. Because it will look like spam. Put their email as the Reply-To instead.

Odds are sda3 is where Manjaro was installed. Use `mount` to see all the mount points.

If you liked using objects more and just weren't sure how to, it goes like $ua_type = $api_result->device->type; Looks a lot like the array syntax, right?

Guidance for what? Surely you understand what the problem was before? What's left to fix?

We're getting a bit out of sync now but whatever. You see "category". That means the code is trying to show the category page. You don't have anything set up for $text on the category page.

(sigh) Do you know what "category" means? Why you are seeing it on the page now? Where that value is coming from?

I can pretty conclusively tell you that the code is not running as you've portrayed. Programming isn't magical or random: computers follow a very specific set of instructions (code) as entered by a programmer. I could be missing something obvious, but assuming not then the code you've shown will not cause the problems you have. There is something going on that we can't see because we're not sitting in front of your computer, and ignoring us by saying "well that's how it is" and "it's not my code" doesn't help us and more importantly doesn't help you. How about you post the entire contents of the PHP half of this? Unedited, as it is right now.

find . -name .htaccess | while read L; do [ -e "$L.dev" ] || cp "$L" "$L.dev"; done Find all .htaccess files, and for each one test if there exists a .htaccess.dev and if not copy from the .htaccess.

Then what I said is still true...

Then either none of those conditional blocks are running, or you have the PT_LoadPage code in the wrong place. As a test, make sure this works: 'TEXT' => 'Test text'

A RecursiveDirectoryIterator (searches directories recursively) wrapped in a RecursiveCallbackFilterIterator (lets you give it a function to filter to just the files you want) wrapped in a RecursiveIteratorIterator (lets you foreach over it without having to care about the recursion) can find all the .htaccess files. If you're considering a non-PHP approach because you only need to do this once then I would probably just do it manually. Surely there aren't too many of these, right?

That code should work. The problem is somewhere else - either you're looking at the wrong pages or you're somehow not changing the value of those variables.

Given that this is historical data and so not expected to change, I would assign each record a number according to the air date. Which could be the episode number. So you could just fetch the previous and next episodes according to the episode number.

The file is being executed through that PT_LoadPage function. Variables defined in your first PHP file will not be accessible in the second file. If you want to send a value through then do it like the other values are being sent through.

How is searchEquipmentTable being called? The idea is to remove IDs (unless you need them for something else), and possibly add a class or two in a couple places, so that you can find the elements you need in a generic way. For example, if you always have the whole form dedicated to this search (like you won't do two searchable tables in the same form) then you can identify the search input as being the textbox with the (eg) "table-search" class, and the table to search is the only table inside the form. element.querySelector() is the key. An alternative is to keep IDs but use data attributes so the Javascript can read them to determine what to do. Like the form or something would have a data-table-search-input="#equipmentTableSearch" and the input would have a data-table-search="#equipmentTable". The initial code knows how to find the form/something, looks up the data-table-search-input attribute and .querySelector()s it to find the input, then looks up the data-table-search attribute and .querySelectors() it too to find the table. One of those approaches might make more sense based on the rest of the page as well as how similar the other pages and their search forms are.

Did you restart Apache/nginx/PHP so the change takes effect?

"Related" how? The PHP needs to be executed before the HTML, and they must both happen during the same request (so like without any redirects).

Switch from IDs to classes. Or data attributes. What's the HTML for the table, including the input?