kagg-design/kagg-fast-post-generator

Plugin to generate a big number of posts.

kagg-fast-post-generator's Issues

Randomize dates

I created a site, generated 100 posts, 20 users and 1000 comments.
So everything was generated in December 2021 and December 2022.

Here is an example for comments:

All comments were generated either today, or a year ago on 2021/12/13.

Posts:

It would really nice if the posts/comments could be spread across the past year, for example.

SQLite support

I tried to lulz your plugin here: https://playground.wordpress.net/?php=7.4&wp=6.4&storage=none&networking=yes

Obviously as expected, it does not work on SQLite.

Given that it looks like SQLite might be merged into core - would you consider adding a support for it?

Super low priority by every possible means.

Move the plugin's page to "Tools" section of the Admin Panel

I think, "Tools" section is the better place for this plugin since it's a tool ¯\_(ツ)_/¯

Comments by logged out users

Right now all the generated comments are for the users that exist on a site.
It would be super handy if it was possible to allow comments generated by site visitors not users (so basically by logged out users).
Maybe even define the % (so by setting 10% - this number of comments will be generated by logged in users, everything else - by logged-out users).

unable to activate

When I try to activate your extension I've a fatal :

( ! ) Warning: require_once(/home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/vendor/autoload.php): failed to open stream: No such file or directory in /home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/plugin.php on line 59
Call Stack
#	Time	Memory	Function	Location
1	0.0002	369424	{main}( )	.../plugins.php:0
2	0.2076	14231576	plugin_sandbox_scrape( $plugin = 'kagg-fast-post-generator-old/plugin.php' )	.../plugins.php:192
3	0.2077	14231904	include_once( '/home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/plugin.php )	.../plugin.php:2288

( ! ) Fatal error: require_once(): Failed opening required '/home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/vendor/autoload.php' (include_path='.:/usr/share/php:/www/wp-content/pear') in /home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/plugin.php on line 59
Call Stack
#	Time	Memory	Function	Location
1	0.0002	369424	{main}( )	.../plugins.php:0
2	0.2076	14231576	plugin_sandbox_scrape( $plugin = 'kagg-fast-post-generator-old/plugin.php' )	.../plugins.php:192
3	0.2077	14231904	include_once( '/home/csn/Local Sites/wp59/app/public/wp-content/plugins/kagg-fast-post-generator-old/plugin.php )	.../plugin.php:2288

It seem that vendor/autoload.php does not exist

Thank you

Support for other languages

Hi,

Do you plan to add languages other than English, like Russian?

For example: FakerPHP or FishText API.

Make `mysqli.allow_local_infile` warning persistent

When the plugin is activated for the first time, it will check for allow_local_infile setting is On.

On a page reload the warning is gone. This is causing couple problems:

1. Low experienced site owner may be confused because they could not remember the setting name if they want to send it to server/hosting tech support.
2. Someone might think they did perform the correct configuration and the warning isn't displayed any more because everything is ok (while it's still not ok)

Could we keep the warning visible until the mysqli.allow_local_infile is properly set up? It doesn't look redundant since the plugin could not operate normally before that at all.

If mysql user can't read CSV-file the plugin doesn't handle such situation

SHOW VARIABLES query runs on every admin page

This query SHOW VARIABLES LIKE 'secure_file_priv' is run on every page inside the wp-admin area.

I think it makes more sense to run it only on the "KAGG Fast Post Generator" page.

Comments dates are not consistent

Hey Igor,

I was playing with comments data generated by the plugin, and found that comments dates are not consistent with comments IDs.

So, comment_ID may be lower (meaning it was inserted into DB earlier) but its comment_date value is later than those comments that were generated later.

Example:

commend_ID	comment_date
161	2022-12-17 14:50:52
653	2022-11-05 08:16:21

So comment 161 was inserted in the DB earlier but its date is later than in comment 653 that was inserted later. This is not how the WordPress commenting system works.
Of course, WP supports changing the comment_date when editing the comment which can screw the results, but that's not how WP works out of the box (without editing).

This makes the whole set of data unreliable.