Jump to content

maxxd

Gurus
  • Posts

    1,660
  • Joined

  • Last visited

  • Days Won

    52

Posts posted by maxxd

  1. If you're pulling data from WordPress but not using it as the CMS (so basically, it's headless) then your page doesn't know what to do with the WordPress functions you're calling. That's what I mean by mixing CMSs, you're relying on the PHPjabbers stuff to handle the bracketed text replacement and WordPress to hand the_posts(), the_title(), the_excerpt(), etc. Pick one - make sure you include the proper WordPress handler code, or use WordPress and include the PHPjabber script in the WordPress template file and use it there.

  2. It looks like you're mixing CMSs? WordPress by itself doesn't understand mustache notation, so {SCMS_CONTENT_2} means nothing to it unless you're using a theme or plugin that parses that code.

    1 hour ago, Strider64 said:

    You're not echoing out the content

    the_title() will echo by default - you can turn echo off by passing false to the third parameter.

  3. 3 hours ago, acebase said:

    It's a gigantic mess of spaghetti!

    It's very easy to do that with WordPress if you're not careful.

    3 hours ago, acebase said:

    The only thing I'm missing would be Wordpress practices - setting up tables and using hooks and other things.

    Hit the codex. The documentation for WordPress is actually quite good.

  4. 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.

    • Like 1
  5. On 2/24/2021 at 4:32 AM, guymclarenza said:

    Can anyone tell me why and how to make the previous one work.

    The first code block doesn't work because of variable scope in PHP. The $fcont inside the class is not the same $fcont as the one outside the class. There are several ways to fix the issue, and given where you appear to be in learning PHP your solution in the second code block is fine albeit not ideal. Another solution is to build the string in the class method and return it to the calling code, which then prints the result. The best and most advanced option is to use a templating language like Twig or Blade, though that's probably going to be a topic for the future.

  6. I pretty much agree with kicken, but feel the need to throw in my own two cents.

    First off, tip #3 is something everyone who codes should live by. To add to it, don't string together a million conditionals - I'm currently dealing with a code base that has a 180-line if-elseif-else tree and it makes me wanna barf. For what is supposed to be a conditional logic operation, this is shockingly devoid of both condition and logic.

    Personally, I think any sort of hard and fast numerical limit on function/method/class width or length is kinda manufactured. Use judgment and good formatting. For the width, break across lines when it becomes hard to read. For instance, there's nothing inherently wrong with this code:

    if(empty($_POST['firstname']) || empty($_POST['lastname'])){
     // ...
    }

    Plenty easy to read, but if you've got more validation to do, this becomes a nightmare and should be broken, like so:

    if(
    		   empty($_POST['firstname'])
    		|| empty($_POST['lastname'])
    		|| empty($_POST['middlename'])
    		|| empty($_POST['fieldicareabout'])
    		|| empty($_POST['anotherimportantfield'])
    		|| empty($_POST['myrefridgerator'])
    	){
     // ...
    }

    Granted, this board's indenting is far larger than mine in VSCode, but hopefully you get the point.

    As far as length, methods should do one thing, and objects should handle one situation. What you've got now is what's called a god object in OOP, and it's - as you're finding - difficult to reason about and maintain. On the other hand, the issue you can run into with one function per file is that it can become a mess of code relationship that's hard to follow if you're not extremely diligent. It also absolutely requires a full test suite because chances are you'll be including the same file in multiple places, and this can lead to hard to find bugs when you forget you use a function somewhere in a different part of the code.

    And finally, just to beat the horse some more, format everything appropriately. I've spent untold hours at work trying to parse SQL queries because the original author wrote them out in one long line instead of using line breaks and indenting to make it make sense. Obviously PHP isn't Python or Ruby in that indentation doesn't actually affect the code, but there's a reason the authors of some programming languages chose to use indentation instead of brackets or curly braces - it makes the code easier to read, and illuminates the intention of the functionality.

    Wait - I lied; one more thing (it's late but I'm not sleepy and my mind is going, sorry). Absolutely use descriptive and appropriate method and variable names, but document as well. Just because your method is called `applySalesTax` doesn't mean I feel like parsing the entire method to figure out how or why you're applying sales tax. For instance you can assume that people know that sales tax is different across states, but if you don't charge sales tax in North Carolina as a business decision or due to a legal loophole, put that in the docblock.

    • Like 1
  7. AFAIR, if you were timing out you'd be seeing a 504 Bad Gateway error, so it's a problem with the form handling code. If you've turned on error reporting and verified it through phpinfo(), you should be seeing the problem in the browser. Make sure you've enabled 'display_startup_errors' in the same php.ini - your script may be crashing before it even gets to your code.

  8. 23 hours ago, simona6 said:

    Sorry the UK bit is the end of the domain.. .co.uk/?s=......... and so on.  It's not a page as such.

    So how would I write a function that checks if they are logged in, and checks from the array of user roles. 

    If not logged in, they we hide the DIV.  But if they are logged in, but their user role is NOT one of those specified we hide the DIV.

    The way WordPress (and most of the internet, nowadays) works is that it uses a pattern called a front controller. Every request is routed through the 'index.php' file, so https://mydomain.uk is a page, and everything after the question mark is a URL variable. For instance, 's' is specifically what WordPress looks for to know it's being asked to search for something. Click the links in my earlier post and you'll have your answer - use is_logged_in in the template file and the template_redirect action hook.

    If you don't know how to do that, start here.

  9. While I agree with requinix in theory, it also kinda depends on the business logic. Laravel allows for multiple database connections, and with cloud services like AWS you can redirect to specific servers based on subdomain (as well as path and a variety of other criteria). So, it's possible that companya.project.com can be hosted on a completely separate server than companyb.project.com. If you're expecting each company's data set to get very large it may be best to separate the databases based on those subdomains and either use separate connections in Laravel config or use CI/CD variables to control the actual database credentials via the .env file.

  10. It's not as succinct as one could hope, but this should work.

    let vals = [];
    let fields = document.getElementsByName('roles[]');
    for(let item of fields){
      vals.push(item.value);
    }
    console.log(JSON.stringify(vals));

    I had thought the forEach() method would work, but had trouble with that, and of course the return is a NodeList instead of a true Array so using map() wouldn't work either.

  11. Also, some mail services will mark a message as spam or not deliver it if the 'from' address doesn't match the actual domain from which the email is sent. You set from to the email of the user filling out the form - probably not going to match your domain. If your mail actually isn't going anywhere or is ending up in the spam folder, try changing the 'from' header to 'contact@jtconfirmation.co.za'.

  12. There are plenty of sites that will tell you if the username you're choosing is unavailable - I'm pretty sure github does this, but it's been a while so I could be wrong. While I agree that if you're making the user hit submit with both password and username, don't tell the user whether it's the username or password that's incorrect; however if your goal is to let the user know before they hit send, you're gonna have to do it. As for usernames of 'PHP' or 'admin', you shouldn't be using that alone to determine capability to begin with. Hopefully your system has not only password protection, but roles to disallow major system changes from all but specific users. So in the grand scheme of things, it doesn't really matter what the user name is as long as it's not 'Little Bobby Tables' and/or you use prepared statements to protect against SQL-injection and avoid using exec(). Use AJAX to check for the username after it's been entered and let the user know if it's not available. Just make sure the passwords are strong - there are some libraries and information available if you Google.

  13. I remember at one point that composer 2 wasn't compatible in some ways with earlier versions of php, but that doesn't appear to be the case at this point. However, if you absolutely need different versions of composer and want to do it easily, consider using docker.

    Re-reading this thread I'm not sure the exact use case (it's late after a long day, so I may have just missed it) but it certainly seems like you're making things more complicated than they need to be.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.