WebKoding
Forum Replies Created
-
A different angle from the export-and-reimport route, and one that answers your "must not change content, URLs, SEO settings or categories" requirement directly: WP-CLI can write post meta without ever touching the post row.
First, find the real meta keys. Open one recipe that already has the five fields filled in and run:
wp post meta list
Recipe themes and plugins prefix their keys, so the field labelled "Preparation Time" in the editor is very often not stored as prep_time. This matters more than the rest of the job: if you guess the key, the write will succeed, the values will be in the database, and the template will still show nothing - and you will not discover it until all 170 are done.
Then export the list to review in a spreadsheet:
wp post list --post_type=post --format=csv --fields=ID,post_title > recipes.csv
Two things worth deciding in the spreadsheet rather than in WordPress. Total time is preparation plus cooking, so calculate that column instead of asking anything to estimate it - one less column to review and one less thing to get wrong. And since you are filling the sheet by hand, "only update the empty ones" is decided there: leave a row blank and no command is generated for it. That is a simpler guarantee than configuring an importer to skip non-empty fields.
Then write them one field at a time:
wp post meta update ""
That command writes to the postmeta table and nothing else. It cannot change post_content, the slug, the categories, the featured image, or the fields an SEO plugin keeps in its own meta - which is the assurance an import cannot give you as cheaply, because an importer is capable of touching the post and you are relying on having configured it not to.
Do five posts first and look at them on the front end before running the rest. If the values are in the database but the template is still empty, the key is wrong, and you have five to fix rather than 170.Forum: Everything else WordPress
In reply to: Downloads Versions of my plugin on wordpress.orgI ran the numbers on this rather than guessing, and the download counter does look like it is measuring something other than people.
The daily history is public, so you can check your own plugin:
https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=YOUR-SLUG&limit=60
Three plugins I published in the last two weeks, all small, all with fewer than 10 active installs:
- 137 downloads over 12 days. Release day was 35, the day I pushed a new version was 30, the day after release was 20. Those three days are 62% of the total. Every other day averages 5.8.
- 159 over 15 days. Same shape: 41 on release day, 33 on the day of the new version, 17 the day after release. That is 57% of the total in three days; the rest average 5.7.
- Released three days ago: 43, then 21, then 7.
The part I did not expect is that the second spike lands exactly on the day a new version is committed, not on a day anything was announced. Nobody discovered the plugin that day – a new zip appeared, and mirrors and scanners fetched it. So the counter counts fetches of the file, and every release you make inflates it again.
Which means the ratio you are worried about is not really 1000 downloads to 6 users. Strip the release-day spikes and what is left is the trickle, and that trickle is the number worth watching.
On the version graph specifically: active_installs is rounded down and reports 0 for anything under 10, so with a handful of installs there is nothing to draw a percentage from. That is a display floor, not your users refusing to update.