maxxd

You can use plain php curl, but honestly I think it'll be easier to deal with if you use Guzzle. I find it much easier, especially when dealing with passing tokens and keys and whatnot; as the docs say:
$client = new GuzzleHttp\Client(); $res = $client->request('GET', 'https://api.github.com/user', [ 'auth' => ['user', 'pass'] ]); echo $res->getStatusCode(); // "200" echo $res->getHeader('content-type')[0]; // 'application/json; charset=utf8' echo $res->getBody(); // {"type":"User"...' Give it a shot and come back with code if something goes weird.

The data you're sending from AJAX doesn't include a 'submit' index, which loginizer.php requires to do anything.

Personally I like to refine and/or finesse the data as necessary in the controller before it reaches the view. This sets up basically very dumb views where any business logic is taken care of before the view is rendered. However, part of the system I'm currently working on does pretty much what you describe and passes raw data directly to the view where it decides what to display and how and it works just fine. As requinix points out, some degree of coupling is pretty much unavoidable so I guess it depends on what's easiest for you reason about.

Typically this happens when PHP outputs an error. Check your console and see what the output is from the server. Looking at your $queryForCheckInLijst, it may be a SQL error - it looks like you've added a couple column names without commas. I haven't looked through the rest of the code, but that's a place to start.

The cookie superglobal in PHP is $_COOKIE[], not $COOKIE[]. So that may be part of the problem you're seeing. And as long as you're using the jQuery cookie plugin (which I assume you are from the snippet you posted), you should be able to read the contents of the cookie with:
console.log($.cookie('calc')); See this SO question for more details. Also note that the jQuery cookie plugin has been deprecated in favor of a non-jQuery dependent version.

add_filter('woocommerce_bookings_remove_inactive_cart_time', changeDeleteTime()); function changeDeleteTime(){     return time() + ( 30 * 24 * 60 * 60 ); } That should work. What errors are you getting?
 
By the way, I truly mean should - I've not tested it.

Do me a favor and explain what you mean by 'raw text'.
 
The widget() function is what renders in the widget area in WordPress. The following part of the code outputs an unordered list of the data.
// Construct unorganized list for each row echo '<ul class="mycred-this-weeks-leaderboard">'; foreach ( $leaderboard as $position => $data ) { $avatar = get_avatar( $data->user_id, 32 ); echo '<li>' . $avatar . $data->display_name . ' with ' . $mycred->format_creds( $data->total ) . '</li>'; } echo '</ul>'; If it's not spitting out a list as described, it's possible there's escaping on the content. Look for a line in your functions.php file that starts with the following:
add_filter('the_content', ... After the comma is a function name. Find that function in the functions.php file and see what it does. An escape function in WordPress (like esc_attr(), for instance) will convert special characters into HTML entities, so your output would actually be the HTML markup itself. Now, understand that escaping is important and very much needs to be there, but there are several different escape functions in WordPress, and some are more appropriate than others for some situations.

Then this is a simple JavaScript question, not a PHP question. Create an change event handler to change the background color to the value selected by the user. Note that 'amber' is not recognized by Firefox as a valid color, so you'll probably want to do hex values, but this should get you started:
 
HTML:
<tr> <td id='capacity_cell' style='width:300px;height:250px;background-color:grey;'> <label for='capacity'>Capacity</label> <select id='capacity'> <option value=''>Select One</option> <option value='green'>Green</option> <option value='amber'>Amber</option> <option value='red'>Red</option> <option value='black'>Black</option> </select> </td> </tr> jQuery:
$(function(){ $('#capacity').change(function(e){ var bg = $(this).val(); $('#capacity_cell').css({ backgroundColor: bg }); }); });

There's no way for us to tell why it's failing right now as the SQL looks fine. What you need to do is check the results of the query. See if the query failed; if it did check the error using mysqli_error().
if(!mysqli_query($con, "UPDATE news SET news_title='$news_title', news_content='$news_content', publish='$publish', facebook='$facebook' WHERE news_id='$news_id'")){ print("<p>Don't print the error to screen in a real application; but for testing purposes the error is ".mysqli_error($con)."</p>"); } Also, please note that you're inviting SQL injection by putting suspect data ($_POST values) directly into the SQL. Look into prepared statements - honestly, here's where you're going to find PDO much easier to deal with.

You've got output before the call to session_start(). If I'm not mistaken, WordPress replaces shortcode at the point that it encounters it in the loop content. Which means there's the header file, and processing, all the HTML, and any post content before that shortcode that's output to screen before the session_start() call. I'd recommend starting the session either using the init hook, or at the top of your functions sheet.

Admittedly, it's late so I may be overlooking something, but your connection string looks like it should work assuming the username, password, database name, and host are correct. The only thing I see that looks a little off is the space between the host and dbname assignment. The dsn strings that I've seen and used in the past don't have a space there. So perhaps changing
$db_connection = new PDO("mysql:host=$host; dbname=$db_name", $db_user, $password); to
$db_connection = new PDO("mysql:host=$host;dbname=$db_name", $db_user, $password); might help? To make sure the constants.php file is being included, just add a die('Hi there! This is constants.php'); at the top of the script an see if it prints out or not. Might be a path issue, although if you have error reporting turned on that should tell you the file isn't found.
 
That having been said, the entire logic behind the class you've designed makes no sense. You're assigning the DB connection to a method-scope variable, then calling a static object method to attempt to return the variable you just assigned to the method-scope variable (and which the static object method knows nothing about) to another method-scope variable?

The insert statement is good - you're using a prepared statement. Do the same with the select statement. Also, don't use md5() for your password - MD5 has been pretty much obsolete for quite a while now due to the fact that it's not secure. Use password_hash() and password_verify().
 
Those are a couple things that jumped out at me on a quick look.

I don't know Laravel, but it certainly looks like a function that gets all the data from a table called Flight, then passes that data to a template file that is rendered to the user.

Things like database connections, configuration files, and ... well, honestly any functionality file, be it a class or function sheet, should be exactly where you put it. The idea of a database connection file being in one of two places is a bit scary - that means it could be within the webroot, where it's viewable under the right circumstances, or it could be above the webroot, where it's not. And - most importantly - your application doesn't know which it is. Needless to say, above the webroot is better.
 
How it's accessed from there depends on your system - if you're using a front controller pattern with a routing system, for instance, everything is going through a single entry point - index.php in the main webroot. From there, you always know where your includes directory is ('../includes/'). If you're using separate files for each page and serving them from within separate directories, then you'll have to do a bit more calculation to get it. However, if you're still using this style, you're probably duplicating a bit of code and content already, so it shouldn't add too much to your current overhead.