Jump to content

maxxd

Gurus
  • Posts

    1,655
  • Joined

  • Last visited

  • Days Won

    51

Posts posted by maxxd

  1. Mailgun and Sendgrid are pretty good, yeah. Although - in my experience - even they sometimes seem like they're guessing at statistics.

    Edit: I realize I sound like I'm shitting on email services; I'm not. They're far more reliable than home-grown or most native solutions, but I remember a campaign I worked that reported like 80% open rate and 65% click-through on Sendgrid and I was like "uhhh ... nah, dude. I don't think so."

  2. Don't worry about aggregating the data on the way into the database; do that while you're selecting the data from the database. All SQL dialects are built to handle large amounts of data efficiently by default (obviously the table schema design helps, but the point stands) so don't exclude data you may be able to use later.

  3. I wouldn't use php's native mail function to be honest. PHPMailer is easier, more robust, and more reliable as both requinix and ginerjm have pointed out. That having been said, if your project requires mail stats you may be better off looking into a service. MailChimp has an API that doesn't completely suck and ConstantContact has an API - both of them have methods in place to gather interaction stats, though honestly even those can be dubious at times.

  4. The URL you say is your link to update is forms/decs-update.php?id=<?=$contact['id']?>&decs_id=<?=$decs['id']?>. Your form action is decs-update.php?id=<?=$decs['id']?>.

    To be honest, I don't recommend mixing methods like that. Just echo out the $contact['id'] and $decs['id'] as hidden fields in your form, then check the values using $_POST.

  5. I'm biased toward php, but in my (admittedly long ago) experience with .net, php is just a better experience for internet app and site development. As I remember it, php was easier to read and reason about, the conditional structures were easier to follow, etc. I vaguely remember having to jump through several hoops in .net to complete what was a fairly simple loop structure in php - though again, this may be tinted by my preference for php in general so ymmv.

  6. You can run PHP on IIS, sure. For the most part, PHP frameworks don't really care what server software it's running on as long as the correct version of PHP is supported and it has the necessary extensions installed. Now, to be honest, I personally wouldn't recommend running PHP on IIS but that's up to you.

    And no, PHP and ASP.NET are not interchangeable and they probably won't coexist peacefully on the same machine but I haven't tried so ... :shrug:.

  7. Making an ajax call every 1-2 seconds wouldn't cause what you're seeing, but if you're appending the full dataset into a JavaScript array on every ajax return that could be it. If you initialize the page with a JavaScript array containing all messages and then append all messages again every 1-2 seconds, that array is going to grow exponentially very quickly and an out of memory error would be a distinct possibility.

    Make sure you're returning new messages only from the PHP so only those get appended to the array or object.

  8. OK - couple questions. Can you get to the site main directory (also known as the document root) on the command line, and are you working locally or on a remote server? If the answer to the first question is yes then the answer to the second matters less, but if so please come back and we'll all talk about development best practices.

    So let's assume your working directory is your document root and is located at /var/www/html. First and foremost, you'll use your terminal application to navigate into that directory:

    cd /var/www/html

    Then, you use Composer to install the package:

    composer require phpoffice/phpspreadsheet

    You should now see a /var/www/html/vendor directory. Again, in this example your php files should be located in /var/www/html.

    Then, in your php files, you'll add the following in order to use the package:

    <?php
    require_once($_SERVER['DOCUMENT_ROOT'].'/vendor/autoload.php');
    
    use PhpOffice\PhpSpreadsheet\Spreadsheet;
    
    $spreadsheet = new Spreadsheet();

    Just to be perfectly clear, this is not the best structure for a website - you should have all your vendor files above the document root and they should be included by the files in your document root, but that's a step too far for right now and I don't want to overwhelm.

  9. What errors did you get? Assuming you ran composer install phpoffice/phpspreadsheet as per the instructions, you'll have a composer.json and composer.lock file in your main directory, and an autoload.php in the /vendor directory.

  10. I think it's because the term is rather ambiguous and may be inappropriate to the situation. You don't really "spawn" a web page, you serve it. So if you have a URL on AWS that serves the page or function or method you're looking for, link or call to it from the calling process or page. Otherwise, you need to more completely describe what it is you're trying to do so that we can help you. You're also taking about MFA, so that muddies the terminology as well - are you sending an application request to an AWS endpoint and not getting the response you expect?

    Describe what the system should be doing, what's actually happening, and give pertinent code showing how you're doing what you're currently doing.

    I have a feeling there's a disconnect here - as I said, the concept of spawning a new process doesn't really have a corollary in web development, though admittedly it may apply in web application development if you're using web workers. And some asynchronous PHP libraries, maybe.  It can get weird so specificity helps.

  11. requinix told you how to fix it and you didn't do that. You need to use absolute URLs in your image src attributes:

    <img src="this/is/wrong.png">

    vs

    <img src="/this/is/right.png">

    You don't need to create a new directory and move images into it, just update your source attributes.

×
×
  • 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.