maxxd

Change this $text = ''; $category_id = ''; $videos = array(); to die("<pre>".var_export($page, true)."</pre>"); $text = ''; $category_id = ''; $videos = array(); and see what it says.

You're assigning a value to both variables, then sending both variables to PT_LoadPage(), where you print both out. So by showing both, your code is actually doing exactly what you're asking it to do. You've already got some logic to determine the page. Inside those logic blocks, you can set a value to $text that is specific to that page. Then only include $text as a parameter of PT_LoadPage(). That way, you'll know the variable is set no matter what page you're on but it'll be populated with page-specific data. You could also continue the way you're going and look into template conditional logic tags, but at that point you're mixing your logic and display code to an extant that's - IMO - missing the point of using a templating language anyway.

I think the way you're doing it is not a bad solution. Grab an array of the IDs (select only the ID in order to make it a quick query) at first page load on initial visit to the site and store that in session or a cookie - it's not like the historical air date is going to change, so the data doesn't need to be all that fresh, honestly. Then you can grab the next or previous episode by the episode ID from the previously set and stored array.

You could also accomplish this with CSS using flex and order. It won't affect the actual data structure, which could present some issues with screen readers in this case, but if that's not a concern it'll get the job done.

True. Unfortunately, I think some newer folk don't know that what they're seeing is WP-specific code and not standard PHP.

Try the posts_orderby hook to alter the ORDER BY clause of the main query. More information here. You'll want to use is_search() to make sure you're dealing with the search query only. ginerjm, unfortunately this is the standard way of writing a template for WordPress. There are other ways out there (one of my favorites - Timber - allows the use of Twig templates), but they're non-standard and all depend on either a plugin or specific theme.

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.

Right beneath the live that reads //ADDED TO UPDATE change $node = new stdClass(); to $node = $result['node']; and see what happens. I'm assuming you know that the code presents a possibility for race condition issues, so you may want to make sure that either save_node() or EntityFieldQuery have some sort of safeguard in place. Again, I know very little about Drupal. Also, I'm not sure if it's just how the code pasted in or not, but formatting your code properly makes it much easier to read - I actually couldn't find where you'd instantiated $event in the foreach() loop until I'd copied the code, pasted it into my IDE, and formatted it. If it is just a by-product of pasting the existing code into the browser, then please disregard all of this last little bit.

Everybody here was new to PHP at one point, so that's not a problem! Please post your code as it is now. I think I may be a bit confused - did you add the code from reply #5 to the conditional branch where the event was found, or where it wasn't? The impression that I got before I posted my reply was that you'd added those lines to the 'true' branch of the conditional, and that may not be the case at this point. Basically, I don't see where you're getting the $node variable from if the event is found in the database. It may be Drupal thing (not terribly familiar with Drupal), but it seems to me that the record you want is stored in $result['node'], not in $node.

What did it accomplish? Anything at all? You're assigning a value to a variable and then doing nothing at all with that variable or value as far as I can tell. You have other issues with the code - you need to escape output, for example, not to mention that if you're just learning PHP it's a great time to learn a templating system like Twig as well, but as to your original question I'd start there.

Well, that escalated quickly...

If you're updating an existing record, wouldn't setting $node to the value of $result['node'] (in order to get the existing event record) make more sense than creating a new standard object - like you do when the event doesn't exist?

Actually, I feel like you've just proven my point. It's easy to dismiss the benefits of consolidating code when taking the simple and frankly rather inane example UML diagram literally, but when you expand to a real-world scope, it makes a lot of sense in some situations. While I'm not saying that abstract classes should always be used, I am saying don't discount them out of hand. In much the same way, I think interfaces are an incredibly useful tool as well, but they don't make sense in all situations and I don't think every class should implement one unless you really, really like typing and (potentially) maintaining the same code in multiple places. Or you're using a framework that builds them for you - I remember Yii would generate skeleton controllers and pretty full models automatically. I'm not using it now, so I don't know if it still does, and I don't know if that's a thing that most frameworks do these days.

But those very special assumptions are the interface. Poor class design (public properties, inflexible constructor, etc.) don't mean the pattern is useless or even bad. Sure, when you use a simple interface, the workings of the methods are up to the concrete classes, but then again they're entirely up to the concrete classes. In this instance, it's a pretty safe bet that both a contractor and an employee have a name. So in both cases, you'll be using toString() (which, in all honestly, should be getName() or something else that actually makes sense - again, it's bad design, not a bad pattern) to print that name. Why write that code in both classes? If the contractor happens to be a corporate entity, create a new CorporateContractor class and overwrite the toString() method there - you're only doing it once, and it's a specific and telling use case. Note the getSalary() method is abstract - if I'm not mistaken, that method has to be implemented in any class that extends from the Person class. So, in effect, it's very similar to your interface except that you're not writing and maintaining the same chunk of code in multiple classes.

If you're never going to use anything other than the HTML class, there's no need for an interface. Interfaces dictate consistency of functionality across your application. If a method is defined in an interface, the class that implements that interface must implement that method. This means that every class in your *VarDumper family will have a consistent API and you don't have to worry about which specific VarDumper you're using - just call the dump() method because you know for a fact it's there, and you know what parameters need to be passed and in which order. Another great thing about interfaces is that the implementing class inherits the interface type for use in typecasting. So, if you're working a class that makes use of a VarDumper class, you don't need to write a separate method for callCLIVarDumper(CLVarDumper $dumper){} and callHTMLVarDumper(HTMLVarDumper $dumper){} You'd simply use: callVarDumper(VarDumper $dumper){} Again, because of the defined interface, the master class doesn't really care what type of VarDumper it's using, it just knows it can use it and how to do so. However, all three of the above are valid and will work, so if you do need the specificity of calling a method to work with, for example, only an HTMLVarDumper you can do that as well. Hopefully this makes some sense - I'm only about halfway through my second cup of coffee...

My wife has an iPhone 6, and for some odd reason any images she'd post to Facebook for a while were showing up either rotated 90 or 180 degrees. No obvious rhyme or reason for it. Not much help to you, I know, but at least you know you're not alone with the issue...

What version of PHP is the staging server using? date_create_from_format() [DateTime::createFromFormat()] was introduced in 5.3.0 according to the docs.

Look for a call to the function apply_filters() right around this area. The apply_filters() and do_action() functions are how WordPress allows themes and plugin to programmatically override core and extended functionality. If there is an apply_filter() call, I would think it would allow you to change the contents of the array the above function is creating. Of course, without knowing what theme you're using or what the rest of the code around this function looks like, I can't guarantee anything.

Also, if this is a home-spun solution, is there a reason you've determined that the best way to understand the meaning of the 'd' array values is by position instead of named index? I know it's done a lot, but if you're creating this yourself why not make it a bit easier on everyone now and in the future by using logically named indexes?

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.

I'd highly recommend switching from mysqli to PDO if it's not too late for your project. It's much, much easier to deal with, especially regarding prepared statements. Just remember to turn off emulate prepared statements, which is on by default for reasons no one has yet been able to adequately explain...

It does let you run JavaScript willy-nilly in a post or page body though, so there's always that...

Actually, it's safe to say there are several problems with the way this is written. There are problems with the PHP (malformed conditional, malformed conditional block, nested double quotes in output), the WordPress specific code (malformed get_post_meta() call), the actual output (inline styling), and the basic tenets of modern programming (duplicate code). If you turn on error reporting (either PHP's error reporting or set WordPress's WP_DEBUG constant to true), you should see several rather helpful error messages.

<?php foreach($images as $image): $opena = !empty($image['caption']) ? '<a href="'.esc_attr($image['caption']).'" data-lity>' : ''; $closea = !empty($image['caption']) ? "</a>" : ''; ?> <li><?= $opena; ?><img src="<?= esc_attr($image['url']); ?>" alt="<?= esc_attr($image['alt']); ?>"><?= $closea; ?></li> <?php endforeach; ?> Obviously the variable assignments can be refactored into a traditional if() block instead of two ternary statements if that makes it a bit easier to read - kind of up to you. You need to escape output in WordPress - it won't do it for you. Also, what's the data-lity attribute doing? You don't assign it a value anywhere that I see.

Nope, nothing wrong with it at all. In fact, that's typically how it's done.