kicken

In the documentation, it shows you the various options for the privilege level that you can specify. The | separates the possible options and can be read like or. So for the priv_level portion of the GRANT statement you can use either "*" (meaning default database), "*.*" (meaning all databases), "db_name.*" (meaning the entire database db_name), "db_name.tbl_name" (meaning table tbl_name in database db_name), "tbl_name" (meaning table tbl_name in the default database), or "db_name.routine_name" (meaning the routine routine_name in database db_name). Since you want to grant privileges on a specific database, you would use the "db_name.*" option when writing your grant statement. That means you'd write your grant statement like so: grant all on wordpress.* to 'webuser'@'host'

Yes, See the documentation for the GRANT statement. The privilege level can be specified as: priv_level: { * | *.* | db_name.* | db_name.tbl_name | tbl_name | db_name.routine_name } So to set a privilege on an entire DB you would use the db_name.* syntax rather than the db_name.tbl_name syntax you are currently using.

There is an example near the end of the documentation for last_insert_id. Something like this I am guessing. $sql = " UPDATE $table SET item=?, id=LAST_INSERT_ID(id) WHERE id<10 ORDER BY id ASC LIMIT 1; "; //and then $last_id = mysqli_insert_id($conn); echo "Last inserted ID is: " . $last_id;

Use CREATE USER first to create the user account, then grant it the privileges it needs. create user 'webuser' identified by 'abc123'; grant all on wordpress.table to 'webuser'; Your first two grants failed because you are creating a new user. 'webuser'@'localhost' is different from 'webuser'@'host' specified in your create user statement. Your second two failed because you didn't specify a valid privilege type.

If the form is not added until the radio button is changed, the your code adding the event listeners cannot be run until after the radio button is changed either. Alternatively, you add the event listener higher up in the DOM and check the element that triggered the event. For example: document.getElementById("div2").addEventListener("click", displayDate); function displayDate(e){ if (e.target.tagName !== 'INPUT'){ return; } alert('Trigger'); } You callback function is given an event object as it's parameter. That object has a property called target which is a reference to which DOM element triggered the event. Check that DOM element to see if it matches your criteria, in this case that it's an <input> element.

Assuming your while loop is running more than once, you're duplicating your element IDs which results in invalid HTML. ID values must be unique within the document.

Styles set on an element directly (such as through element.style or the style attribute) take precedence over any styles defined in a style sheet. It's best then to avoid setting styles directly and instead just add or remove a class from the element. You can add and remove multiple classes if needed to be able to target specific conditions. See my updated fiddle for an example.

Use a multi-line closure and log the value. divs.forEach(d => { console.log(d); d.classList.remove('active'); }); If you just want to change some colors on click, you can probably do that without JavaScript at all. HTML: <div tabindex="-1">First div</div> <div tabindex="-1">Second div</div> <div tabindex="-1">Third div</div> The tabindex attribute lets you make the div focusable. Having the div focusable allows you to use the :focus css pseudo class. CSS: div { margin: 2rem; padding: 1rem; border: 2px solid #00F; } div[tabindex]:focus { background: #000; color: #fff; }

Set your old timestamp variable to null when the game is started/restarted. this.oldTimeStamp = null; Then in your game loop function, check if it's null and if so store the provided timestamp. if (this.oldTimeStamp===null){ this.oldTimeStamp=timeStamp; } This way your game always starts out at 0 for seconds passed. Currently, your first iteration when the page loads is essentially random as it depends on how long it takes for the browser to run the first game loop after starting the page.

Try adding the indent option.

Formatting values should always be a last-step operation. You want to structure your code so the prices remain as numbers and you can do whatever operations on them you need to do, then only format them right before you display them, for example directly in your template if possible. $price1 = 30; $price2 = 74.99; $bundle = $price1 + $price2; //...anything else //When everything is done and you're ready to display echo getMoneyUSD($price1); echo getMoneyUSD($price2); echo getMoneyUSD($price3); Also, you should know that floating point math can lead to issues due to lack of precision. A common way to avoid these issues is to work with your prices as integers (ie, number of cents) then convert them to decimals as part of the formatting process. Alternatively, you could find a library for dealing with currency values that handles such issues for you.

If it works in the browser, but not in the command line then you probably have different configurations for the two environments. Your system may have multiple php.ini files, one that's used for web stuff and another used for CLI scripts. The output of the phpinfo() function will tell you where the INI file being parsed is. In the php.ini output you provided, you can see all the lines being with ; which means they are all commented out and not active. Try removing the leading ; from the oci lines to enable the extension. The effect should be immediate for CLI, but may need you to restart the webserver or fpm server for webpages.

They need to go somewhere, unless you want to be manually entering them every time the system boots. The config files can have their permissions set so only root is able read them. If you're worried about someone else with root access reading the files, then your problem isn't "how to secure the environment variables?", it's "why does someone you don't trust have root access?". The other common solution is to not make them true environment variables at all and put them in a .env file in your application directory. Make that file readable only by the application's user and use something like symfony/dotenv to load it and access the variables using $_ENV. I do a mix of both in my applications which are based on the Symfony framework. I have SYMFONY_ENV=prod set as an environment variable in the server configuration to ensure it's running in production mode, then a .env.local file in the application directory that has all the secrets for the application.

The FPM workers run in a clean environment via systemd. Setting clear_env in the pool configuration doesn't change that. You will need to either set the variables as part of the service definition in systemd or through the web server so they get passed to the fpm process. For example, if using apache add SetEnv YOUR_VAR the_value to your site configuration. Or set them in your pool configuration explicity with env[YOUR_VAR]=the_value

Greetings, Laravel is popular, but I also find Symfony to be better. A lot of stuff (including Laravel) uses Symfony components under the hood so it's good to know it as well. Symfony uses Twig by default for it's templates. Twig has a lot of features, but at it's most basic level is fairly simple. You make one base template that defines your site structure then put {% block Blah '' %} anywhere that you want to be able to add content. Then you make a second file for your page and use {% extends 'base.html.twig' %} {% block Blah %}<p>The content</p>{% endblock %} To specify the content to be placed in said block. Keep up the learning and it'll all click eventually. PHP is a great and versatile language, and if you use it well and learn good design/architecture (which Symfony helps with I think) you can carry that knowledge over to other languages.