mikeor26
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: wordpress-importer 0.9.5 rejects –rewrite-urls optionoops another typo, the script line has the
"--rewrite_urls"option in the bash script afterStart also (with the double dash) .- This reply was modified 1 month, 1 week ago by mikeor26.
Forum: Fixing WordPress
In reply to: wordpress-importer 0.9.5 rejects –rewrite-urls optionThe command runs in a bash script that forms the “afterStart” for wp-env start, on ubuntu 24.04.4 x64, with wp-env 11.0.2 and WordPress 6.8.2 and wordpress-importer 0.9.5
In the afterStart script it looks like :
wp-env run cli wp import "./${container_file}" --authors=create --user=admin --quietAnd when it runs the output looks like:
Starting 'wp import ./wp-content/data-to-import/acf-fields.xml --authors=create --user=admin --rewrite_urls --quiet' on the cli container.Error: Parameter errors:
unknown –rewrite_urls parameter
✖ Command failed with exit code 1
Command failed with exit code 1Forum: Fixing WordPress
In reply to: wordpress-importer 0.9.5 rejects –rewrite-urls optionI confirm that in my script there are indeed two dashes, and that the error message persists.
It seems the word-processor used to prepare the above question reformatted to make it appear as a single dash, which it is not.
Anyone else have a suggestion?
I received email replies, but I cannot see these responses here in this forum.
Thank you to users who replied, indicating that my approach is OK to use an afterStart script , and giving me the option details viz:
wp-env run cli wp option update date_format 'Y-m-d'
wp-env run cli wp option update time_format 'H:i'
wp-env run cli wp option update permalink_structure '/%postname%/'
wp-env run cli wp rewrite flush --hardThese commands had the desired effect when run from the afterStart script.
Marking this question as resolved.
Forum: Fixing WordPress
In reply to: wp-env automate activating a custom themeThank you for your response, it helped me. and I think there is no issue, because I can get it to work now (although I do not know why it silently failed yesterday, and also why my wp-admin change yesterday got lost).
The
wp theme listshowed my theme along with all the default wordpress themes, and it showed that the active theme had reverted to twentytwentyfive overnight for some reason.Evidently it was a new environment because my custom theme status was inactive, although I had yesterday activated it via the Dashboard in wp-admin. I don’t know what happened to the database in the interim! I am certain the starting directory is identical as I only have a single copy of the custom theme and plugins on my disk.
Anyway while wp-env was running, I then ran the
wp-env run cli wp theme activate mythemetaking care to use the identical slug (name) as reported by the priorwp theme list.This time I got a success message from the
wp theme activate. A subsequentwp-env run cli wp option get templateshowed that my custom theme was the active one. A subsequent wp-env stop and start, followed by querying the active template also showed that my theme was still active.So scripted theme activation appears to work, although I’m puzzled why my manual changes to the database via Dashboard got lost overnight (wp-stop performed before shutdown overnight). I will blame my lack of experience with wp-env.