Jump to content

requinix

Administrators
  • Posts

    14,237
  • Joined

  • Last visited

  • Days Won

    369

Community Answers

  1. requinix's post in Adjust Div Width To Content, And Center It Horizontally On Top Of Another Div was marked as the answer   
    DIVs are block elements by default and will expand their widths to their containers automatically. Give the text centering to its container and make the DIV be either inline or inline-block.
  2. requinix's post in PHP Scheduler/Calender was marked as the answer   
  3. requinix's post in Add descriptor text to output in certain places was marked as the answer   
    Regex would be an easy way to handle this.

    $line = preg_replace('#^=+<br/>$#', '<hr>', $line); $line = preg_replace('#^(\d\d:\d\d) (.*?) (\d{10})<br/>$#', 'Time: $1 - Description: $2 - ID Number: $3', $line);
  4. requinix's post in iimagettfbbox and font file on hosted server was marked as the answer   
    Find out what distro it is then Google the default font path. Might be in /usr/share. If there are any installed at all.
     
    Or just ignore all that and upload the font you want. That's not bad or anything.
  5. requinix's post in Read JSON instead of XML, need some HELP was marked as the answer   
    1. Fix those three lines near the top so they find the right files.
    2. Replace the three stupid pairs of simplexml_load_file/json_encode lines with one that uses file_get_contents to load the JSON data into $json. Keep the json_decode lines.
    3. There is no third step.
     
    That's assuming the JSON structure mirrors the XML structure. If it does not then you have to adjust the code accordingly.
  6. requinix's post in small tweak to rank an array was marked as the answer   
    Without thinking too hard about it,

    sort($ranking);that is the only place in the code that does any kind of sorting, so to reverse the results you would reverse the sorting.
  7. requinix's post in Multiple databases within Instance vs One global database was marked as the answer   
    That's short-sighted. It doesn't matter where data lives as long as the application keeps everything separate, and this only "helps" administrative stuff if you have to work within the database directly (SQL queries and such). But multiple databases like this is almost always a bad idea in the long run. 
    One database is how it should be.
     

    Not really. What matters is how much data there is and how it's organized in the tables - multiple databases won't cause a performance problem simply because there are more than one.  

    That is actually an appropriate concern. It doesn't matter that the data is distributed (in fact that generally makes things more awkward to work with) but having that load distributed is reasonable. If you're at the point where multiple servers is worth the investment, of course. 
    You could have one lower-spec server handling data that's used less frequently or less aggressively (eg, big complicated queries) and another higher-spec server handling the data that gets processed more heavily.
     

    Right.  

    And moving data across servers makes that harder, though IIRC SQL Server has native functionality for that. But if you can JOIN tables across servers in a query, I would expect that the processing has to happen on one server - it's not like the query is split in half and each piece executed by the server housing the associated data. So simply moving the data for the sake of moving it might not actually do you any good if you're querying both servers' data together frequently.  

    No. Not to me. If you have a particular client or three that is putting an exorbitant load on your server then you need do something about getting them a dedicated instance - as in a separate copy of the application and database on separate servers. But in general it should be the same database/server for everyone. 
     
    Meanwhile your thoughts about migration and the distributed architecture I can't help too much with.
     

    Make sure you have proper indexing before thinking about this. Indexes are almost always enough to do the job without separating data.
  8. requinix's post in comma operator v/s binary op was marked as the answer   
    PHP does not have a comma operator.
  9. requinix's post in 3 logical operators not working. was marked as the answer   
    Are you sure you didn't change anything else? What if you delete the addition and have that one line to back to how it was before?
  10. requinix's post in I Need to install split() on php7 was marked as the answer   
    split() worked using POSIX regular expressions, so you might need to look up what you find sometimes.
     
    However \n is a literal character and doesn't need regular expressions.

    explode("\n", $foo)"\|" is a literal pipe character and doesn't need regular expressions either.
    explode("|", $bar)
  11. requinix's post in n00b - displaying content of a specific row from MySQL in a table was marked as the answer   
    If you want a link to /results.php?ID=1 then the HTML looks like

    <a href="/results.php?ID=1">Some text in here</a>Obviously you wouldn't write 1 - instead you'd use the value in $row. 
    As for the table, all you have to do is think in terms of rows and columns. With the table you want, "CREATOR" and "John Smith" would be in the first row and in the first and second columns respectively. Since HTML tables are written as rows containing columns you'd do

    <tr> <th>CREATOR</th> <td>John Smith</td> </tr>Rinse and repeat for the other rows. Remember to remove the header row since your table won't be using one.
  12. requinix's post in Display records on week format was marked as the answer   
    So that's a little bit different from what you originally described... I assume the
    is what you'll be repeating for each week? One table per week? 
    Here's the idea. Since you're "grouping" the tables by week, use a variable to track which week you're looking at. When it's a new week you start a new table.
     
    But before that it helps to rearrange the code a bit. Get the first row before the loop, then fetch new rows at the end.

    <?php $row = mysqli_fetch_array($mquery); ?> <table class="table"> <tr><td>Days</td> <?php while ($row) { echo "<tr><td>".$row['dow']."</td>"; echo "<td>".$row['no_one']."</td>"; echo "<td>".$row['no_two']."</td>"; echo "<td>".$row['no_three']."</td></tr>"; $row = mysqli_fetch_array($mquery); } ?> </tr> </table>The only big difference is that the fetch happens twice, once for the first row and later for subsequent rows. 
    With that change out of the way, here's the overall structure you'll be creating:

    $row = fetch the first row $week = empty while ($row) { if $week is empty { start a new table $week = current week } show the data from $row $row = fetch the next row if no $row or $week != the week from the new $row { end the current table $week = empty } }Take a minute to understand how that works:1. Start without any $week information
    2. When the first $row comes in you'll start a new table and update $week
    3. Show that $row and fetch the next one
    4a. If the new $row matches the current $week then don't do anything and just continue on
    4b. If the new $row does not match the current $week, or if there aren't any more rows at all, then finish off the table
    5. Keep going until there are no more rows
     
    Steps 2 and 4 are important because HTML tables have starting and ending pieces that you need to make sure are created properly - you can't just output each $row and put some "break" in between them when the week changes.
     
    Taking that structure and turning it into PHP code creates this:

    <?php $row = mysqli_fetch_array($mquery); $week = null; while ($row) { if (!$week) { echo '<table class="table">'; echo '<tr><td>Days</td>'; $week = $row["week"]; } echo "<tr><td>".$row['dow']."</td>"; echo "<td>".$row['no_one']."</td>"; echo "<td>".$row['no_two']."</td>"; echo "<td>".$row['no_three']."</td></tr>"; $row = mysqli_fetch_array($mquery); if (!$row || $week != $row["week"]) { echo '</table>'; $week = null; } } ?>
  13. requinix's post in Processing data and identifying whether valid was marked as the answer   
    So this is for a different part of the application than the RPC messages?
     
    Then I'd still follow what the spec says (regarding this particular bit) simply for the consistency - every part of the system uses the same result/error structure so there's no confusion.
  14. requinix's post in Redirecting a user that is not logged in? was marked as the answer   
    soapbox

    //header('Location: /');You cannot redirect if there has been any output. Move that bit of logic to the "top" of your script.
  15. requinix's post in access.log was marked as the answer   
    No, actually a 404 would have been a good (better) thing than the 200. 404 means the server didn't know what to do with the request. As in it didn't correspond to a file or directory and it didn't have any other way to interpret what it might mean (such as through URL rewriting). A 200 means it was able to handle it in some way that seemed reasonable.
     
    Though uncommonly used, servers are supposed to accept absolute URLs in there - a place which should normally only have relative URLs. Requesting "http://whatever.your.website.is/foo" results in an HTTP request containing

    GET /foo HTTP/1.1 Host: whatever.your.website.is(plus other stuff). With our fake request, Apache reinterprets it
    HEAD http://wap.ip138.com/ HTTP/1.1 Host: whatever.your.website.isto instead mean
    HEAD / HTTP/1.1 Host: wap.ip138.comThat is, it rewrites the request URI and the Host according to the absolute URL that was used. 
    Since your server doesn't handle the "wap.ip138.com" domain, Apache picks the default virtualhost instead. It then runs the request like normal, which results in the output we saw.
     
    See also
  16. requinix's post in textarea; break on white space while entering text was marked as the answer   
    That's how they normally work...
  17. requinix's post in Equality between two object's attributes was marked as the answer   
    I too would use array_intersect_key for the property names. For the value types I'd do array_map+gettype+array_intersect_assoc.
  18. requinix's post in linearize relationship was marked as the answer   
    If you want to prefer values in master over values in admin then you need a second JOIN for that. Then you can get the correct value with a COALESCE

    COALESCE(master's value, admin's value)A more obvious solution would be to OR the franch table in
    LEFT JOIN admin as vc ON vd.mid = vc.xid OR fe.fid = vc.xidbut that only works if you know the value can't be in both admin tables (or else you'd get two matching rows). 
    But really you shouldn't have this I-don't-know-which-table-the-value-is-in issue to begin with. It suggests there are data problems.
  19. requinix's post in use of $_SESSION[] space was marked as the answer   
    It isn't that precise to begin with. Sessions are generally driven by files; when PHP loads up a session it reads the file, interprets what's inside, then restores it as $_SESSION. Then when the request is done it can/might save the session data back into that file. Naturally, adding more data means PHP will take a bit longer to read the file (start the session) and finish the request (save the session). It's all still quite fast so you don't have to worry about every single value you put in there, but you might actually notice a performance impact if you were to store, say, 1000 search results. It's not like you need those results on every page - just that there are results, then only on the search page do you need to get them all.
     

    It's all about trade-offs. By storing the query you have less in the session but loading the search page means doing the search over again. By storing the results you have all that available immediately but you do have to store it all. 
    Consider how fast the query is, how many results there are on average, how much data it takes to "remember" those results (ie, if you put them in the session), and how often the search page will be revisited.
     
    There's also another thing to consider: if you change the code in the future. If someone visits your site and gets a session, then you change your code, and they come back, they will still be using the old session. So if that code you change involves session code you need to be prepared to handle "old" sessions. It can get trickier if you stop storing some data but don't ever clean it up.
    For example, if you originally stored the search results but decided to store the query, the code would probably work fine because old users don't have a query stored, but if they have search results stored then those will stick around and get loaded/unloaded with every page until the session naturally expires.
     
    But that's applicable to anything involving sessions, not just this.
     

    Personally I would store the search parameters. Not the SELECT query itself but the information they entered in the search form. So the search text and whatever else you prompt for (eg, type of thing to search for, or places to search in). The code then takes that search information and continues from there. Alternatively you store the search query. Alternatively alternatively you'd store the search results.
     
    Whatever approach, the change to the code is about the same.
  20. requinix's post in Changing navbar if user is logged on or not was marked as the answer   
    logout stuff

    login stuff
  21. requinix's post in How do I see the source code of a web-page? - and what happened to FireBug was marked as the answer   
    I suggest trying one of these:

    It might not be 100% correct but if you can rub a few brain cells together you should be able to figure it out.
  22. requinix's post in Resize image upload to HTML page was marked as the answer   
    You can't make an image smaller and have it look exactly the same. You will lose some quality. You can try a thumbnail but you'll probably come up with a result that looks like the resized one.
  23. requinix's post in changing the database for a different country. was marked as the answer   
    Indeed. 

    That is a reasonable reason to split them: separate businesses and sites.  

    It would be and that's the problem: making the system more complex without any significant reason to do so. 

    It's simple. You don't have to think about which database you need to query if all the data is in one place. It's also good to not segregate everything based on data that can change (country), which then means you have to worry about making sure the data is stored in the right place if/when it changes.
  24. requinix's post in REST api using php - how to parse url resource id for POST was marked as the answer   
    Exactly.  

    $_REQUEST is a combination of other variables: normally $_GET and $_POST but also often $_COOKIE. They'll overwrite each other in a specific order. It's convenient to have the one variable for everything but means you can't be sure where a particular value comes from - you might think you're getting it from the URL ($_GET) but it could have been passed via a form ($_POST) or a cookie ($_COOKIE). 
    Using $_GET/POST/COOKIE specifically is considered a best practice.
  25. requinix's post in How to access a multiarray with PHP. was marked as the answer   
    echo [0]['MLSNumber']; echo [0][0]['MLSNumber']; echo [0][0]['MLSNumber'];There is no way those will work because they don't even mention $myarray. The variable has to be in there. Obviously. 

    echo $myarray['MLSNumber']; echo $myarray[0]['MLSNumber'];Better, but you're missing a very important part that can be seen quite clearly in the print_r output:
    [DATA] => Array (
    Array ( [DATA] => Array ( [0] => Array ( [CurrentPrice] => 135000.00 [MLSNumber] => 857252Look at the whole structure and read from left to right through the indentation: 
    $myarray is

    Array (an array containing
    [DATA] => Array (a "DATA" element, which is also an array containing
    [0] => Array (a 0 element, alongside a 1 and 2, which is also an array containing
    [MLSNumber] => 857252an "MLSNumber". 
    Put them all together in order and you get

    $myarray["DATA"][0]["MLSNumber"]Since the second index is a number 0-2 that means you'll need a loop to get all the elements. Like a foreach.
    foreach ($myarray["DATA"] as $data) { // $data substitutes for the [0] element echo $data["MLSNumber"];
×
×
  • 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.