Is there a way to change what the database is named when using the wp db export command?
When I type wp db export on one of my WordPress sites, the database gets named {dbname}-{Y-m-d}-{random-hash}.sql, which is correct according to WP-CLI Commands. When I run the same command on one of my other sites, it names the db dbname.sql (which I prefer).
Is there a way I can have wp db export name the exported db dbname.sql?
I know I can type wp db export dbname.sql but I just wanted to see if the default when typing wp db export could be modified.
You are probably using different versions of WP-CLI on both machines. Up until version 1.2.0 the default was just {dbname}.sql. Since version 1.2.1 it defaults to {dbname}-{Y-m-d}-{random-hash}.sql.
Verify the WP-CLI versions with
wp --version
There is no way to override the default itself other than you just did by passing it a filename. But there still is a way to get the database name dynamically and then name the file after it by using the --porcelain option to only get the filename and then chain two wp db export commands together like that:
# Exports the database named '{dbname}.sql'.
wp db export $(wp db export --porcelain | cut -f1 -d "-").sql
cut -f1 -d "-" cuts the porcelain output with the first -. Since databases can't have dashes in their name, this seems a pretty save method to be used on your system with the newer WP-CLI version.
To have one command to be used on both your machines, you may need to find a way to check for the existence of - characters first, and cut only if a - exists. Or install a WP-CLI lower than version 1.2.1 on both machines.
Related
I am trying to use cl-sql for database access to sqlite3.
But I am getting the error
Couldn't load foreign libraries "libsqlite3", "sqlite3". (searched CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS*: (#P"/usr/lib/clsql/" #P"/usr/lib/"))
The same is with sqlite.
I have installed sqlite3 using apt-get and there is a file libsqlite.so.0 in /usr/lib directory.
I also tried to build sqlite3 from source but I couldn't get the so file. What is that I am doing wrong?
Your problem is that cl-sql has a third party dependency. If you inspect the implementation of cl-sql (probably under "~/quicklisp/dists/quicklisp/software/clsql-202011220-git/db-sqlite3/sqlite3-loader.lisp") you will see that the function database-type-load-foreign is trying to load a library named either "libsqlite3" or "sqlite3".
Depending on your operating system this is either looking for a .dll or .so with exactly one of those names.
Given that the version of of libsqlite.so has a different name on your particular distribution of linux, you have a number of different options to make this library work.
Install a version of sqlite3 with the correct binary
Create a soft link to your binary that redirects via ln -s /usr/lib/libsqlite.so.0 /usr/lib/libsqlite3.so (assuming libsqlite.so.0 is the file that clsql is looking for)
Add new paths to CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS* to point to the correct binary if it is installed elsewhere (via clsql:push-libary-path)
I'm deploying openstack- stein version on ubuntu pro 18.04 LTS.
I come across these lines when configuring keystone - identity service, as of this article.
Would anybody please explain how to set this following configuration:
$ export OS_USERNAME=admin
$ export OS_PASSWORD=ADMIN_PASS
$ export OS_PROJECT_NAME=admin
$ export OS_USER_DOMAIN_NAME=Default
$ export OS_PROJECT_DOMAIN_NAME=Default
$ export OS_AUTH_URL=http://controller:5000/v3
$ export OS_IDENTITY_API_VERSION=3
If I'm already in root mode, is there any need to these env variables ?
If the question helped, up-vote it.
Whether you are root or not has no meaning for the openstack command. The OpenStack admin user has nothing to do with the Linux root user.
You don't need the variables, but your command line becomes very long without them, for example openstack --os-username=admin --os-password=ADMIN_PASS --os-project-name=admin --os-user-domain-name=Default --os-project-domain-name=Default --os-auth-url=http://controller:5000/v3 --os-identity-api-version=3 server list. These variables are the most convenient way to tell the openstack command under which identity it should perform its actions.
How to set them? Type them on the command line, but the most common method is putting them in a file that you source. You can then have several such files for several different identities, such as the admin and demo identities in the linked document, which allows you to quickly switch from one identity to the other.
In short, put those commands in admin-openrc.sh, then source admin-openrc.sh when you need to use openstack-cli with administrative account.
I am using flyway db version 6.0.8 in my local macbook pro with MySQL Database Integration.
I have placed a create table script under ~/sql and using below command to migrate. However its not creating table its only creating "flyway_schema_history" but not the actual table.
Conf file:
flyway.user=flyway
flyway.url=jdbc:mysql://127.0.0.1:3306/db
Below are the flyway logs:-
Flyway Community Edition 6.0.8 by Redgate
Database: jdbc:mysql://127.0.0.1:3306/DB (MySQL 8.0)
Successfully validated 0 migrations (execution time 00:00.005s)
Creating Schema History table `db`.`flyway_schema_history` with baseline ...
Successfully baselined schema with version: 1
Current version of schema `db`: 1
Schema `db` is up to date. No migration necessary.```
Flyway follows the simple path. And that is convention.
When creating Flyway migration file or even locating it, you have to follow conventions.
For example, the path cannot be some random folder:
Also the naming:
The file name consists of the following parts:
Prefix: V for versioned (configurable), U for undo (configurable) and R for repeatable migrations (configurable)
Version: Version with dots or underscores separate as many parts as you like (Not for repeatable migrations)
Separator: __ (two underscores) (configurable)
Description: Underscores or spaces separate the words
Suffix: .sql (configurable)
Resource : https://flywaydb.org/documentation/migrations
If you run flyway with the -X parameter, it will print out the locations it is searching for migrations.
e.g.
flyway migrate -X
This should help you figure out where it is searching, vs where you have put your migration files.
Can I use wp-cli to return a value for the local Wordpress installation root directory?
Ideally I'd like a wp-cli command like "wp pathname" that returns "user/myname/sites/project_a" when invoked from inside Projects A's installation, and "user/myname/sites/project_b" when invoked inside Project B.
I'm writing a bash script to dump a Wordpress database and do a little post-processing on it. I'm calling on wp-cli to make the dump; I'd also like to use wp-cli to find the pathname for the installation so that I can guarantee than when invoked anywhere in the current installation the dumpfile will always be written to "some/path/to/project_name/dbdumps/". I can't find anything in the documentation about install directory.
wp-cli seems like the right tool for the job because it's Wordpress aware, but I am happy to use some other tool that is capable of discovering my install directory; perhaps a creative and elegant use of the find command, or a way to report the value of Wordpress's FTP_BASE variable?
I ended up doing this with bash, not wp-cli, by using BASH_SOURCE.
There doesn't appear to be a way to do this from within wp-cli itself, but since my script is always running from inside the Wordpress install directory it doesn't matter — I can just find my script's location.
I am new to SQLite3.
I am trying to create a DB in the shell. When I run the shell, it already shows:
SQLite version 3..
Enter ".help" for instructions ..
Enter SQL...
Enter SQL statements terminated with a ";"
I read somewhere that I should be able to type "$" and codes like "$ sqlite3 mynotes.db"
Now, I need to be able to name my DB (like "mynotes.db") and be able to decide in which folder I want it to be saved.
Can someone help me? Cheers!
The $ somewhere was supposed to be a prompt of some shell (command processor), where you start sqlite3 and specify database name (which is created if does not exists).
If you're running sqlite3 without a shell (by clicking on sqlite3.exe?), it's time to try another way. CMD.EXE on Windows is as good for this job as a typical Unix shell.
As of the folder where the database will be: either cd to this folder before you run sqlite3 mynotes.db, or specify full pathname to the database: sqlite3 "C:\Users\Me\Documents and Settings\mynotes.db" (double quotes are needed when argument contains spaces).
When sqlite3 is started with no parameters, the database will be in memory. Sqlite3 supports "attaching" other databases (see ATTACH DATABASE description). This way, you can create and open on-disks databases even if starting sqlite3 with parameters is impossible for some reason (or too hard).