I've battled with this question for hours now, searching far and wide through the web finding several guides to setup testing for individual plugins which created new a installation of WordPress and created a new empty database as testing ground for said plugin.
However, what I wanted was to test all my plugins at the same time, as many have integrations with each other and have their own configurations already set in the database which would need to be re-inserted into the newly created test database.
So, I simply edited the file bin/install-wp-tests.sh as described below:
In the function install_wp() include the line at the end of the function: cp -a /$USER/wordpress/wp-content/. $WP_CORE_DIR/wp-content/
In the function create_db(), change content of function to:
mysqldump $USER_wordpress > dump.sql --user="$DB_USER" --password="$DB_PASS"$EXTRA
mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA
mysql $DB_NAME < dump.sql --user="$DB_USER" --password="$DB_PASS"$EXTRA
(Note: In my case $USER_wordpress is the name of the wordpress databse, and /$USER/wordpress/wp-content/ is the absolute path to wp-content.)
This way, the tests are made using your entire current installation of wordpress including all plugins you've installed or created, and the your current database data.
To load your plugins, you need to specify them on the function _manually_load_plugin() on the file tests/bootstrap.php, by including the plugin like so:
require rtrim( sys_get_temp_dir(), '/\\' ) . '/wordpress/wp-content/plugins/' . 'exampleplugin/exampleplugin.php';
I've used the following guides:
https://poweredbycoffee.co.uk/unit-testing-with-wordpress/
https://maheshwaghmare.com/wordpress/blog/phpunit-tests/
https://wpmudev.com/blog/unit-testing-wordpress-plugins-phpunit/
https://sanjeebaryal.com.np/fixing-issues-while-setting-up-php-unit-tests-for-wordpress-plugins/
But non of them answered the fundamental question of how to include all your plugins and database configurations for your tests, so you could test multiple plugins inside the same test and using all your plugin configurations already set inside you db.
Related
I'm using hydra to log hyperparameters of experiments.
#hydra.main(config_name="config", config_path="../conf")
def evaluate_experiment(cfg: DictConfig) -> None:
print(OmegaConf.to_yaml(cfg))
...
Sometimes I want to do a dry run to check something. For this I don't need any saved parameters, so I'm wondering how I can disable the savings to the filesystem completely in this case?
The answer from Omry Yadan works well if you want to solve this using the CLI. However, you can also add these flags to your config file such that you don't have to type them every time you run your script. If you want to go this route, make sure you add the following items in your root config file:
defaults:
- _self_
- override hydra/hydra_logging: disabled
- override hydra/job_logging: disabled
hydra:
output_subdir: null
run:
dir: .
There is an enhancement request aimed at Hydra 1.1 to support disabling working directory management.
Working directory management is doing many things:
Creating a working directory for the run
Changing the working directory to the created dir.
There are other related features:
Saving log files
Saving files like config.yaml and hydra.yaml into .hydra in the working directory.
Different features has different ways to disable them:
To prevent the creation of a working directory, you can override hydra.run.dir to ..
To prevent saving the files into .hydra, override hydra.output_subdir to null.
To prevent the creation of logging files, you can disable logging output of hydra/hydra_logging and hydra/job_logging, see this.
A complete example might look like:
$ python foo.py hydra.run.dir=. hydra.output_subdir=null hydra/job_logging=disabled hydra/hydra_logging=disabled
Note that as always you can also override those config values through your config file.
We have tried to migrate some SQL versions in a single database and it went well. When to tried to implement the migrations for multiple databases at the same time by passing multiple config files is failing.
The issue is it takes only the last config file and the migration is performed only for the database mentioned in the last config file, when passed the multiple config files in "-configFiles" parameter.
Below is the screenshot of the same, it took only flywayconfdb.conf file and left other files.
[oracle#localhost flyway-5.1.4]$ ./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flyway.conf,/home/oracle/flyway/flyway-5.1.4/conf/flywayjiradb.conf,/home/oracle/flyway/flyway-5.1.4/conf/flywayconfdb.conf info
Flyway Community Edition 5.1.4 by Boxfuse
Database: jdbc:oracle:thin:#//XXXXXXXXX:1521/confdb (Oracle 12.2)
Schema version: << Empty Schema >>
+----------+---------+-------------+------+--------------+-------+
| Category | Version | Description | Type | Installed On | State |
+----------+---------+-------------+------+--------------+-------+
| No migrations found |
+----------+---------+-------------+------+--------------+-------+
Please help us in resolving the same.
Flyway merges the config files. It doesn't do a separate migration for each one.
For each config file, Flyway adds the content to a Properties map. Properties has only one value per key, so if the same key appears in a second config file it would overwrite the previous value. This is why it seems like just the settings from the last config file are used.
It allows you to define some common settings somewhere, for example in ~/flyway.conf, which could be merged with some more specific settings, e.g. in individual projects.
But it doesn't allow you to migrate multiple databases in a single run. You need to run Flyway once per database:
./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flywayjiradb.conf info
./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flywayconfdb.conf info
The documentation describes the Overriding Order as:
Command-line arguments
Environment variables
Custom config files
<current-dir>/flyway.conf
<user-home>/flyway.conf
<install-dir>/conf/flyway.conf
Flyway command-line defaults
With settings defined higher up the list having greater precedence.
The documentation gives the following example:
The means that if for example flyway.url is both present in a config
file and passed as -url= from the command-line, the command-line
argument will take precedence and be used.
The Custom config files (-configFiles) lines could be expanded as:
Command-line arguments
Environment variables
Custom config file n
...
Custom config file 2
Custom config file 1
<current-dir>/flyway.conf
<user-home>/flyway.conf
<install-dir>/conf/flyway.conf
Flyway command-line defaults
And a corresponding example could be:
The means that if for example flyway.url is both present in custom config file 1 and custom config file 2, the custom config file 2 settings will take precedence and be used.
Similarly, if the flyway.url was also in custom config file n that would override that setting from custom config file 2.
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I'm currently using the Qt-Installer-Framework to create a setup for my application. Everything works fine for now except one thing:
If I install it to any location but C:\Program Files\MyApp, the installer won't create the registry entry for Programs and Features!
Is there a way to tell the installer to always do this?
Edit:
After trying out vairous different combinations, I do know now where the problem comes from:
If I try to install as current user only (set the AllUsers variable to false), it will always work and create an entry in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}.
If I install for all users, however, it will try to create a key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}. This will only work, if the installer has to elevate it's operations during installation (because I chose a directory I need admin rights for).
So, the error is: The installer won't elevate itself to create the "global" registry entry and thus fails to create it. Any ideas on how to fix it?
Here the link which has answer to this question.
Add the following line to your component's package xml file:
#<RequiresAdminRights>true</RequiresAdminRights>#
And use this line in your script file:
#component.addElevatedOperation("Execute", "someCommand");#
instead of
#component.addOperation("Execute", "someCommand");#
There is boolean installer.gainAdminRights() to gain elevated privileges during runtime but you will have to add it to an installer script (in packages meta directory) something alike
function Component()
{
if (!installer.isInstaller())
{
if (allUsers && installer.gainAdminRights())
{
//Set registry global
} else {
//Set registry local
}
}
}
I would like to set the configuration of my symfony2 project using environment variables.
In the server I have defined:
SYMFONY__DATABASE__USER
SYMFONY__DATABASE__PASSWORD
SYMFONY__DATABASE__NAME
SYMFONY__DATABASE__HOST
SYMFONY__DATABASE__DRIVER
My parameters.yml.dist looks like this:
#app/config/parameters.yml.dist
parameters:
database_host: "%database.host%"
database_port: ~
database_name: "%database.name%"
database_user: "%database.user%"
database_password: "%database.password%"
database_driver: "%database.driver%"
when I run composer I get an exception
composer install --dev --no-interaction --prefer-source
[Symfony\Component\DependencyInjection\Exception\ParameterNotFoundException]
You have requested a non-existent parameter "database.driver". Did you mean one of these: "database_user", "database_driver"?
These variables are defined in the server so I can modify the parameters.yml.dist to define these values. But this does not seams the right way, because wat I really want to use are the environment variables.
Note: I want to read this environment variables in travis, heroku and my vagrant machine. I only want to have in the repository the vagrant machine variables.
Which is the proper way to do this?
How should look my parameters.yml.dist?
Looks you are doing everything okay.
Here is the complete documentation for Setting Environment Variables which I believe you already read.
What is important to note is this:
Also, in order for your console to work (which does not use Apache),
you must export these as shell variables. On a Unix system, you can
run the following:
$ export SYMFONY__DATABASE__USER=user
$ export SYMFONY__DATABASE__PASSWORD=secret
I remember once I have a similar issue, I was setting everything on APACHE, but when running commands it wasn't working because I forgot to EXPORT the variables on the system.
Be aware that using export is a temp solution, if you reset your server those values will be lost, you will need to setup in a permanent way according to your OS.
I think you solved this long time ago, but the problem is actually that you have 2 _ between DATABASE and USER and the parser for this have a string replace function that replaces every __ with a . .
For your example to work you should have written like this:
SYMFONY__DATABASE_USER -> database_user
SYMFONY__DATABASE__USER -> database.user
You can try this bundle if your system version is >= 2.6.2:
This bundle provides a way to read parameters from environment
variables at runtime. The value defined in the container parameter is
used as fallback when the environment variable is not available.