Jump to content

kicken

Gurus
  • Posts

    4,694
  • Joined

  • Last visited

  • Days Won

    177

Everything posted by kicken

  1. The problem is that you are trying to print_r the result. The object created by that library is large and recursive so you can't just easily dump it.
  2. Add it to your join's ON clause, not the WHERE clause.
  3. It's a little more complicated to setup, but I personally prefer using something like pdf-puppeteer. It essentially spins up a browser to render the page then generate the PDF so you can use most all your modern CSS/HTML (with some limitations) to design the page. I've used it in a few projects and can generally just render the same HTML/CSS as I normally use but without the header/footer and a extra 'pdf' class on the <html> tag. You just have to have node available on the server, create a little javascript program to accept your HTML and generate the PDF then use exec to run it. If you have dedicated hosting or a VPS then it should be relatively simple to setup. If your on shared hosting you'll likely have to ask your host if they support such a thing.
  4. Can you not just check which user logged in and what day it is then check the schedule for their shift? If you just try and check a persons shift when the log in and they may login many times than that won't really work by itself. You need to either have a defined schedule or some sort of clock in/clock out feature to that they use at the start and end of their shift.
  5. Make it so you can submit your form data to a script. Read your form data in the script using $_GET or $_POST depending on your form method. Create your query string from the form data. Concatenate the query string to your base URL. Issue your redirect to the new location.
  6. date_default_timezone_set Setup the timezone to the one you want. For example: date_default_timezone_set('America/Los_Angeles') Then just use your date functions normally.
  7. I tend to just stick to using jQuery form for consistency. If I'm already loading jQuery on the page then I'm not going to do something like document.getElementById('blah'), I'll just do $('#blah')[0]. There's a little extra overhead using the jQuery syntax, but the code consistency is more important IMO and it's also shorter to type. That said, for simple things like accessing the value/name of an element in a callback or target of an event I will sometimes just access the property directly rather than using jQuery. For example if making a simple popup handler, I'd likely just do: $('a.popup').click(function(e){ e.preventDefault(); window.open(e.target.href); }); If I want to use jQuery for any reason though in said callback though, then I'll just use it consistently. For example if I wanted to add a data-options attribute for window options, I would use jQuery for that and as a result also for the href. $('a.popup').click(function(e){ e.preventDefault(); var $target = $(e.target); var options = $target.data('options') || ''; window.open($target.prop('href'), 'popup', options); });
  8. All of your if statements are outside of your for loop, meaning they will only run once after your loop completes. I think maybe you want them inside the for loop. Making that change makes the result for 200 match what you posted. Adding a clause to only run the first calculation when x is less than 200 fixes the 201 result. Also, the way your if statements are structured if $x is say 650 you will run each of the formula up to that, ie: $a += $x * round($x + 7 * pow(4, ($x / 290))); $a += $x * round($x + 11 * pow(4, ($x / 280))); $a += $x * round($x + 19 * pow(4, ($x / 270))); When I am guessing you only want to run the last one. If that is correct, then you want to change your if statements to be a chain of if..elseif..else statements that check the ranges using < rather than >, ie if ($x < 200){ ... } else if ($x < 400){ ... } else if ($x < 600){ ... } ...
  9. I setup a Linux VM and tried this as it should be possible. It seems, at least with Linux MX but probably similar on other distros, that a user needs to be in the audio group in order to access the audio devices. Using the second and third parameters to exec, you can get the output of the command and that is where I started at. The -q flag suppresses the progress bar and the 2>&1 redirects the error output to standard out so it can be captured into $output. exec('/usr/bin/play -q notification.wav 2>&1', $output, $ret); var_dump($output, $ret); This produces the output array(11) { [0]=> string(48) "Home directory not accessible: Permission denied" [1]=> string(48) "Home directory not accessible: Permission denied" [2]=> string(57) "ALSA lib confmisc.c:767:(parse_card) cannot find card '0'" [3]=> string(115) "ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory" [4]=> string(66) "ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings" [5]=> string(110) "ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory" [6]=> string(63) "ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name" [7]=> string(109) "ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory" [8]=> string(82) "ALSA lib conf.c:5047:(snd_config_expand) Evaluate error: No such file or directory" [9]=> string(63) "ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default" [10]=> string(24) "Floating point exception" } int(136) With the default PHP-FPM setup the PHP script runs as user www-data. The first two errors about the home directory are due to that user's home directory (/var/www) not being writable by the user. I fixed this by changing ownership of /var/www to www-data with chown -R www-data:www-data /var/www The remaining errors are due to the sound devices (in /dev/snd/) being limited in access to users in the audio group. This I fixed by adding the audio group to the list of groups www-data belongs to using usermod -G audio www-data After those changes and restarting Apache and PHP-FPM I was able to hear the sound when loading my test script.
  10. Does /usr/bin/play exist? If not you need to install it first. You need to find some program that will allow you to play media from the command line. Just test things out via a terminal or ssh session until you get it working that way, then take whatever command you come up with and put that into your PHP page with exec(). This is all assuming the computer running apache and the one you want the sound played on are the same. If they are not you will need another solution.
  11. Nope, not a valid assumption. From privacy.com: Using their service it sounds like you can just enter whatever billing info you want. Doesn't have to be your real info. Now what about the corporate/non-profit group that wants all their employees to have an account and pays for them using a single corporate credit card? Uh oh, they can't, or you have to up your limit again to however many employees they have. Yes, having a bunch of accounts for a single card may be fishy and worth attention, but outright trying to deny it isn't really the best solution. You add that fact as an input into your filtering system. That combined with other data can then determine if an account might be trouble and then take action such as flag the account for manual review and/or shadow ban it Yes, because it's a silly restriction that doesn't effectively solve the problem. It'll cause issues for legitimate customers and only be a very minor inconvenience for the real trouble makers. For example you just side-stepped the whole stolen credit cards issue. Even your relaxed name/zip code hash won't solve that because each card will have different details.
  12. Doctrine does it's queries in a more or less fixed sequence that is designed around entity relationships and foreign keys. See this old bug report (UnitOfWork commit order problem) and the code for information. That doesn't always play well with other unique constraints, as you discovered in your list ordering problem. As mentioned in that thread though, there's something to be said for over-using unique constraints, make sure you really need one. For situations doctrine doesn't handle well then the work around is usually to use force queries to run in a particular order by using EntityManager::flush() frequently. I don't use pgsql so I'm not familiar with the deferred constraints but if they seem to provide a solution then it may be worth exploring. However I'd first look at the code and see if there is a solution there through a different design or just removing the constraint.
  13. Not gonna like, this was TL;DR after a few posts and sounds just like previous threads where we tell you something is a bad idea/wont work and you just push back. However, I'll reply anyway. None of those places try to turn a credit card into an identity like you are trying to do. They use the card for what it is, a payment method. Any place that is actually interested in a persons identity will require a government issued ID. Your asking for a persons billing details. Whether you store that or not isn't that relevant, just asking for it will deter a ton of people from even considering signing up for your site. That is simply too much personal info. Now if you want to require payment and think your content is good enough people will pay for it then fine. Don't think that because your not storing that payment data that people won't care that your asking for it. They will, and many will consider it a deal breaker. Storing the name and last 4 in plain text would be fine by PCI standards as far as I understand, no need to even hash it. And here's the crux of why your idea is DOA and not worth even doing. How does it stop what you just said you want to stop? If they are coming back with new card numbers then what good is comparing the old one going to do? This is all you need. The sheer fact that you require payment is deterrent enough. Your average troll isn't going to spend money over and over again to keep posting. Even if they do, then so what? Take that extra money you earn and use it to develop a solution that actually works like paid moderators, better content filtering, etc. You need to consider the real world, not your little fantasy world where people will just re-used the same card, get denied and say "Well darn, they got me!" Most trouble makers will simply be stopped by the fact they have to pay. Once you ban them they will be gone and not try to come back. The trouble makers who are not bothered by the payment will have no trouble defeating your little card check. Most likely they won't care because it won't be their money, they will be using a list of stolen credit cards and they will just move on to the next card in the list. For those who actually are using their own money, they will just sign up for some virtual card number service (if they don't already have one) So the end result is that the only people you'll stop are those who genuinely want to join your community and want to help their friends/family join also by offering to pay their subscription cost for them. They won't be able to due to your stupid little check for duplicate cards. Maybe they will be smart/motivated enough to get a virtual card number and work around the problem, but most likely they will just get turned off to the whole idea and at best, won't buy a sub for their friend or at worst will cancel their sub and stop using the site all together. So how do you accomplish your utopia that you want to create? Require a payment to join that's low enough to not deter a sign up, but high enough to deter repeated signups. Higher people (or convince your community) to moderate the site and take down and ban spam/troll accounts quickly. Invest in technology that helps with #2 like easy to use tools and advanced (AI driven?) filtering to catch problem accounts early/quickly Nothing will be perfect, but your current plan isn't even viable.
  14. Your example has missing cells, I assume they are supposed to be populated. Maybe something like this is what you're looking for: <?php $columns = [ range(1, 9), range(10, 19), range(20, 29), range(30, 39), range(40, 49), range(50, 59), range(60, 69), range(70, 79), range(80, 89), range(90, 99) ]; $number_of_cards = $_GET['cards'] ?? 6; $bingo_cards = []; while (count($bingo_cards) < $number_of_cards){ $card = []; foreach ($columns as $columnRange){ shuffle($columnRange); $card[] = array_slice($columnRange, 0, 3); } $hash = sha1(json_encode($card)); if (!isset($bingo_cards[$hash])){ $bingo_cards[$hash] = $card; } } foreach ($bingo_cards as $card){ echo '<table>'; for ($row = 0; $row < 3; $row++){ echo '<tr>'; for ($column = 0; $column < count($columns); $column++){ echo '<td>'.$card[$column][$row].'</td>'; } echo '</tr>'; } echo '</table>'; } For each card that is generated it goes through your $columns array and uses shuffle to randomize the order of the numbers. It then uses array_slice to pick off the first three numbers, one for each row. Finally it hashes the card and checks if that hash exists already to prevent duplicates. Keep in mind this only prevents duplicates for that one generation cycle. If you reload the page to generate more cards then there could be duplicates of the first batch in the second batch. If you want to prevent duplicates across all generation cycles you'll need to track the cards in a file or database. Finally it prints out a simple HTML table for each card.
  15. When PHP initially saves the upload to the temporary folder with a random name (in the form of phpXXXX.tmp). Once the script ends, these files are then deleted. AFAIK PHP won't re-used the name of a file that already exists however so a file won't get overwritten while your trying to handle it. As far as when you generate a file random name to save the file permanently, re-use is something you need to consider. Something like what I showed above is unlikely to generate a duplicate name, however you can guard against it if you want by checking and generating a new one. do { $name = bin2hex(random_bytes(8)); } while (file_exists($name)); Technically even that is subject to a race condition, but the chance is so small I don't worry about it. Adding additional uniqueness on top of the random name will certainly help if that's something you want to do. For example you might use a format of $userName-$randomBytes so each user can have their own set of randomness. That would also allow you to reduce the number of random bytes. Creating a directory per user would similarly reduce the chance of conflict, and would also help prevent having tons of files in a single directory in case you ever need to inspect the directories manually. It basically just boils down to what you feel like implementing and how good is "good enough" for you. My go to these days is to have a simple table that associates files on disk with data in the database and using purely random names that are spread out by the first two letters of the name (ie f1d47394c0bf8d9d gets stored in f1/f1d47394c0bf8d9d).
  16. PHP uploads the files into a temporary directory with a random name, so there's no problem. It's entirely up to you what happens after that. If you want to keep them around long term, you have to move them from that temporary directory to your own storage location. If you just do a simple copy/move to the same name then one or them will be lost. To be clear, you still store the files in a directory, not the DB. You just track what file you stored where using the DB. That allows you to mostly ignore the problem of clashing file names by either naming the file randomly or by using the auto-generated ID of the database record as the files name. It also enables you to store additional meta data about the file (who owns it, when it was uploaded, tags, # of downloads, etc) that can be used for additional features. Like I said, just do that then if you want $storageFolder = './Uploads/'; $nameTemplate = 'Content_%d.jpg'; $counter = getStartingNumber(); foreach ($uploadedFile as $file){ $diskName = bin2hex(random_bytes(8)); $friendlyName = sprintf($nameTemplate, $counter++); copy($file, $storageFolder.$diskName); // INSERT INTO user_file (UserId, DiskName, FriendlyName) VALUES ($userId, $diskName, $friendlyName) } Every user then would have their own Content_1.jpg ... Content_n.jpg without having to worry about file clashes. If you really don't want to use a DB, then the best thing to do would be to have a separate folder for each user, ie ./Uploads/$userId/ then you can still give each user their own Content_$number.jpg file in sequence. If you absolutely have to store everything in one directory then you need to have a lock file. Your script would obtain a lock on that lock file before processing the uploads. Then create your file using fopen($fileName, 'x'); to avoid any potential conflict and copy the data over.
  17. If you want to generate spreadsheets, look into updating to phpoffice/phpspreadsheet.
  18. @phppup, it doesn't matter how the files are stored on disk unless your users are just loading up that directory and viewing the files directly. Store them on disk however you want and just track which files belong to which user in your database then present them to the users that way. You can't really sequence them how you want unless you know ahead of time how many photos each user will be uploading. Say you decide to just +10 for each user so Linda is 1-10, You're 11-20 and Ricky is 21-30. So everyone uploads one photo and now you have Concert_1.jpg, Concert_11.jpg, Concert_21.jpg like you want. But then Linda uploads 20 photos not 10? You have a problem, your files are no longer grouped nicely. Forgot about trying to match the physical storage to some sort of order like that. Just store them. Handle the sorting/ordering in the DB.
  19. That's what the selectors are for (the .container, .divL, .divR etc). Where you put the code in your CSS file probably doesn't matter unless you have multiple selectors trying to override each other or specificity issues. Just put your stuff at the end of the CSS file and see if there's a problem. If there is, then you may need to either adjust where you put it or adjust your selector specificity.
  20. Using a DB allows you to store meta-data separately from the physical file, so the name you actually give the physical file become irrelevant. In my systems all the files are stored with an random name, generated using something like bin2hex(random_bytes(8)); which results in a name like f1d47394c0bf8d9d. That is the name of the file on disk and means there is very little chance of a name collision (though I check anyway for one). That random name is then stored in the database along side whatever the name of the original upload was ($_FILES['blah']['name']) and the original mime type ($_FILES['blah']['type']) so when the user wants to view their files I can show it in their original name and download it with the original type. As a result every user can have their own me.jpg or whatever without any conflicts on the server. If you'd rather have your own naming convention rather than preserving the user's original name then all you do is generate and save your custom name rather than the original, everything else is the same.
  21. Keep in mind that if your web server is a different computer than the one your browsing on, you need to install the CA on the computer your browsing on, not the web server. The same may be true if it's the same computer but different user accounts.
  22. The type of data your processing and how you are loading that data can make a huge impact on the runtime of your scripts. For example if you're querying a database you might be running hundreds or thousands of queries when instead you could run one or two. You might be looping over your result set many times to apply different actions when maybe a little refactoring could do the same in one or two loops. 30 seconds is a long time so either your processing a large amount of data or your code is very inefficient. Breaking up the task across ajax calls may be possible, but you should make sure your PHP code is as efficient as it can be first.
  23. in_array checks the array values, not the keys. To check if a key exists you can use isset or array_key_exists. if (isset($statuses[75352])){ echo 'TRUE'; }
  24. They can be NULL in that case because of the LEFT JOIN. The join condition includes p2.submit_time > p1.submit_time, that means for each row in p1 it will attempt to find a row in p2 where p2's submit_time is greater than p1's submit_time (in addition to the other conditions). If it can't find any row that matches, the all the p2 columns will be null. So, since whatever the most recent entry in p1 is won't be able to find a matching row in p2, p2.id will be null and filtering on that condition in the where clause results in you only receiving the most recent rows from p1.
×
×
  • 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.