Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by requinix

  1. You cannot track the user back through every page they visited. You can track them as they browse your website and you can sometimes (not always!) see what page they were on immediately before the current one.

    The answer is what gw1500se said: if you want to know what someone does after they click a button then track what they do after the click the button. Store each page in an array in the session, and when they get to the page you care about you can pull that array out.

    This is commonly referred to as "conversion tracking" or something similar. It's common for virtually every website that has some ecommerce or monetary aspect to it in order to see what drives people to the "goal" (them spending money) and what does not. So if you want to know more about the concept, there's some keywords for you to research.

  2. 1 hour ago, NotionCommotion said:

    It is my belief that when storing time in the DB, it should always be at UTC.  Agree?



    1 hour ago, NotionCommotion said:

    My question is whether one should work with DateTimes with a specific time zone or only do so when displaying the time to the user?

    I would rather work with them in UTC and alter how they're displayed to the user by literally altering how they're displayed to the user.

    So the first one.

    Play it safe:
    1. Make sure your database abstraction can handle DateTime objects and will translate them to UTC before serializing for storage, then use DateTime instances everywhere
    2. Give yourself one or more functions that can display dates to the user that will adjust the timezone as needed. This is a great way to ensure you display dates uniformly across the site, too.

    Note that if you're working with Immutables, you can do

    $userEventTime->setTimezone(new DateTimeZone(...))->format(...)

    But only if they're immutable. So it might be better to clone instead:

    (clone $userEventTime)->setTimezone(new DateTimeZone(...))->format(...)


  3. If you didn't have a constant named "green" then PHP was converting that to a string for you. But as of PHP 8, that will no longer happen and your script will die.

    PHP raised a warning when it did that. If you didn't see the warning then your PHP is not set up correctly for development.

  4. That happens automatically. A lot of how webpages work for folks like us is declarative, meaning that you tell the browser what you want and it will deal with the how.

    Give the browser a standard web form, built correctly using the right information for the different pieces (eg, the form inputs will need the names "var1" and "var2"), and it will turn the form data that a user enters into the correct URL.

    A skeleton of the form's HTML markup is

    <form action="/" method="get">
      <input type="text" name="var1">
      <input type="text" name="var2">
      <button type="submit">Submit</button>

    That contains the absolute bare minimum information to get the behavior you want: entering "FOO" and "BAR" into the two fields and clicking the button will instruct the browser to go to "/?var1=FOO&var2=BAR".

  5. 38 minutes ago, rene said:

    I just want to write the php code from scratch. I assume the communicating is thru websocket protocol.

    How hard can it be?


    "I want to build a race car from scratch. It has four tires, a steering wheel that pivots them, and windshield wipers. How hard can it be?"

    You aren't just writing PHP code. You're writing PHP code that must observe a binary protocol communicating through a TCP socket. That is something 99% of PHP developers never have to think about in their careers.
    If you have a reliable spec that is relatively easy to understand then perhaps you should start there. Build your code from the ground up by dealing with the little things here and there: a function to send a specific message, a function to read a specific message, a class holding constants for all those magic numbers like 40084 and 40108. Each one of those can be written more or less by itself, and when you have enough of them, you can piece them together into something that actually does the thing you want done.


    38 minutes ago, rene said:

    But i place some print "testx<br />\n";  and noticed the script wouldnt passed the write function. and write must be fwrite i think.

    Now that is something we're suitable to deal with.

    If you didn't create it yourself then yes: PHP doesn't have a "write" function. You will be wanting fwrite.


    38 minutes ago, rene said:

    which raise the question for me, is it tcp or udp.

    The Python script says TCP...

    If it's not TCP then the initial connection to the device will fail. Which is a really easy thing to notice. And since you haven't noticed it, I imagine it hasn't happened.

  6. Without me trying to write the script myself, I see three options:

    1. Dig deeper into the Python code to find out exactly what it does. Specifically, the ModbusClient. Translate everything in there directly to PHP code. Same class names, same method names, same everything.
    2. Use a packet sniffer to see what the Python script sends versus what your script (for the same information) sends.
    3. Keep the Python script, and write your output.log stuff in Python instead of PHP.

  7. 6 hours ago, phppup said:

    The best I can summize that you're eluding to is that errors occur.

    More or less. Try a regular CREATE TABLE with an existing table name and post the full output of what you get back from the server.


    6 hours ago, phppup said:

    But do those errors affect the end result?



    6 hours ago, phppup said:

    In an instance where I do, in fact, know what tables are in my db, the question is even more appropriate: was NOT EXIST created for only lazy db designers??

    I didn't create it so I don't know what the motivation was behind creating it.
    I also said that it was my opinion that using IF NOT EXISTS is a symptom of a problem, and though very many people may believe otherwise, opinions are not facts.

  8. Can't tell from what you've posted, but would you happen to be destroying and recreating the Edit Quote buttons? Such as by replacing the contents of some ancestor container element during an AJAX request?

    Separately from that,

    1. Make the modal show in the success handler. Otherwise it'll show immediately before the AJAX request has finished and filled in the contents. People on the internet are going to notice this effect much more than you will if you happen to be testing this locally or in a local network.
    2. You're attaching the same onclick handler to every single Edit Quote button, and they all do the same thing. That's wasteful. Set up one handler that applies to all of the buttons. If you are doing the destroy/recreate thing then this will also solve your problem.

  9. 2 hours ago, ajoo said:

    I might have said ir wrong though above, port 80 in the container maps to port 8080 on the host which means I would need to access localhost using :8080 provided the container is not exited.

    That's it. "-p X:Y" maps the host's X to the container's Y.

    Make sure the container (and Apache) is running, and that you're browsing to localhost:8080. You should definitely get a connection, even if something else doesn't work.

    • Great Answer 1
  • 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.