Beta Seeder: test data generator 1.0.0 beta 10

1.0.0 Beta 10 can have members register through XenForo's own registration service, so another add-on's reaction to a registration happens for them.

Nothing from Beta 9 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Registration through XenForo's service. seeder:run User -p registered=1, or UserFactory::registered(), saves each member through XenForo's registration service, so an add-on that extends it - to record the browser or the country a member signed up from, say - does so for seeded members as well. XenForo itself mails and alerts nobody: its mail, welcome message and trophies are off for the save. The forum's registration setup decides whether a member is valid or awaiting confirmation or approval, unless moderated() or unconfirmed() says which, and a member the forum's options ask a date of birth or a location of is given one.
• The request a registration arrives on. registered(['REMOTE_ADDR' => '203.0.113.7', 'HTTP_CF_IPCOUNTRY' => 'AU']) sets the address and headers XenForo's request carries during the save. Context::withRequest() does the same for any code of your own, and puts the real request back afterwards, even when that code throws.

Worth knowing​

• registered=1 runs whatever other add-ons do on a registration, which can include sending the member's details out of the forum. The seeder says so before it starts.
• It is not in seeder:validate's sample, for that reason.
• XenForo's spam check is not run: the registration form runs it, not the service.
• The approval queue shows the address from the member's registration in the IP log, which is where a registered member's address goes.
• Beta 9 given registered=1 makes the members the ordinary way, lists the parameter as ignored and exits with 1. The README marks both additions since 1.0.0b10.

1.0.0 Beta 9 seeds profile posts, and can have every member given to a poll vote in it.

Nothing from Beta 8 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Profile posts. seeder:run ProfilePost, or ProfilePostFactory and ProfilePostCommentFactory, write messages one member leaves on another's profile, status updates, and comments on both. They go through XenForo's own profile post and comment creators, so comment counts, dates and latest comments are as a forum leaves them, and each appears in the news feed. Nobody is alerted - not the profile's owner, not the author, not anyone mentioned - and no address is logged.
• A poll every member votes in. ThreadFactory::votedByAll() has every member given to recycle() vote once, rather than a random number of them, for a check that needs to know exactly who voted: ->recycle($voters)->withPoll(4)->votedByAll().

Worth knowing​

• A profile post is by someone other than the profile's owner unless status() says otherwise.
• Profile posts are in seeder:validate's sample. The default seeder does not make them; run ProfilePost after it.
• ProfilePost given to Beta 8 is refused as an unknown seeder. The README marks both additions since 1.0.0b9.

1.0.0 Beta 8 seeds the job queue: weeks of failed jobs, and jobs waiting that will never run.

Nothing from Beta 7 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Failed jobs. seeder:run Job, or FailedJobFactory, writes the history XenForo 2.3 keeps when a job throws: a few faults that recur and many one-offs, thrown from XenForo's code and the libraries it ships, from an add-on and the libraries it ships, from outside the forum, and with no file at all. A fault inside the forum names a real file where there is one. Some messages quote a credential, every one made up and marked SECRET or example.com, for testing whatever displays these to remove them. None is dated within a day of now.
• Jobs in the queue, with JobFactory: some to be run by hand, some tried and waiting to try again. None will ever run. Each is due five to ten years from now and names a job class that does not exist, so a seeded queue has nothing due or stalled.

Worth knowing​

• Neither is in seeder:validate's sample or the default seeder, like the error log.
• XenForo has no entity for either table, so seeder:list names them xf_failed_job and xf_job.
• Job given to Beta 7 is refused as an unknown seeder. The README marks it since 1.0.0b8.

1.0.0 Beta 7 can offer seeded user upgrades for sale, and says so when a factory is used where nothing records what it makes.

Nothing from Beta 6 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• User upgrades offered for sale. UserUpgradeFactory::new()->purchasable(), or -p purchasable=N on the UserUpgrade seeder, lists an upgrade among those members can buy, with its purchase button. It still cannot be bought: the payment profile it names is switched off, and XenForo refuses a purchase through it before writing anything. The seeder says so before it starts.
• A warning for a factory used outside seeder:run. Called from a script or a shell, a factory records nothing, so what it makes is in no batch and seeder:clean cannot remove it. The first thing a process makes that way is now named in the server error log and on standard error. Inside a database transaction - a test that rolls its work back - nothing is said. On XenForo 2.3.0 only standard error carries it: XenForo's own error logging cannot write from a script there.

Worth knowing​

• The README said a seeded upgrade could not be bought because can_purchase was off. It is the switched-off payment profile that stops a purchase; can_purchase only decides whether the upgrade is offered.
• XenForo shows a guest every upgrade as available, whatever can_purchase says, and a command-line script that sets no visitor is a guest. Check the list as a member.
• A parameter from this release given to Beta 6 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b7.

1.0.0 Beta 6 adds categories and forums inside forums, so a run can build a whole forum tree.

Nothing from Beta 5 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Categories. CategoryFactory makes a category, and every forum factory now has in($parent): ForumFactory::new()->in($category), or ->in($forum) for a sub-forum. It takes a node, or the category or forum behind one.
• A forum tree from a seeder. categories on the Default seeder puts the forums inside that many categories, and subforums gives each forum one or more forums inside it. Threads go into every forum, sub-forums included:
  seeder:run Default -p categories=3 -p forums=6 -p subforums=2

Fixed​

• A forum given a parent made earlier in the same run was refused with "Please select a valid parent". XenForo works out where a node sits in the tree at the end of a request; Seeder now has it do that as each node is saved, so a run can make a category and the forums inside it one after another.

Worth knowing​

• Cleaning removes a tree deepest first. A forum you made yourself inside a seeded category is moved up to the category's parent when the category goes, as XenForo does when a category is deleted.
• Through Default, permission_groups puts every member it makes in a group, not only the authors: every member Default makes is an author.
• A parameter from this release given to Beta 5 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b6.

1.0.0 Beta 5 adds permissions on a forum, so seeded members can fall into several permission combinations.

Nothing from Beta 4 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Permissions on a forum. UserGroupFactory::new()->grantingOn($forum, ['forum' => ['viewOthers' => 'deny']]) gives a user group its own permissions on one forum or other node, as the control panel's node permissions do: content_allow, reset or deny for a flag, a number for a limit. A permission a node cannot have is refused.
• Members in several permission combinations. permission_groups on the Thread and Default seeders makes that many groups, each denying its members other members' threads in one of the run's forums, and spreads the authors across them. Code that filters content per member - a digest, a feed, a search - needs members who see different things, and until now every seeded member saw the same.

Fixed​

• A forum parameter naming something that is not a forum made the Thread seeder's authors before refusing. It now refuses before making anything, and says what the node is.

Worth knowing​

• A seeded member's preferences are the forum's default registration values. XenForo ships receive admin email off there, so code that selects members by it finds no seeded member until one is set with state(['Option.receive_admin_email' => true]). The README now says so.
• Deleting a user group empties the forum's cached CSS, so cleaning a batch with permission groups does too, as with the user groups in Beta 3.
• A parameter from this release given to Beta 4 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b5.

1.0.0 Beta 4 adds IP logs, members' histories - the change log, username changes and rejected registrations - and the moderator log.

Nothing from Beta 3 has changed its name, and there is no upgrade step: upload the files and upgrade as usual. One thing behaves differently: see Worth knowing.

New​

• IP logs. ips=1 on the User seeder gives every member an IP log, as XenForo writes one while a member uses the forum: a row for registering, logins up to their last activity (some through a "stay logged in" cookie), logins to the admin control panel for an administrator, and a few changes to the account. On the Thread seeder it also logs the address of every thread and reply, against the post as XenForo does. In a factory: UserFactory::new()->withIpLog(), and withIp() on ThreadFactory and PostFactory.
• Addresses that cannot be real. Every seeded address is from the ranges set aside for documentation (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32). Each member has one to three for a run, and some members share one, so an address can lead to several members. Faker has documentationIp() for your own.
• The change log. changes on the User seeder, or withChanges(), makes members who have changed their account since registering - time zone, location, website, signature, email address, privacy and mail preferences - and some changes made by an administrator, so XenForo's own change log records both kinds of editor.
• Username changes. renamed on the User seeder, or renamed(), gives members earlier names, recorded as approved changes. withUsernameRequest() adds one awaiting approval, in the approval queue, or one rejected by a moderator. The member is not renamed, so nothing they posted has to be rewritten.
• Rejected registrations. rejected on the User seeder, or rejected(), with XenForo's rejection record: by its spam check at registration, or by a moderator after it.
• The moderator log. The ModeratorLog seeder writes a moderator log about members' threads, replies and accounts, in XenForo's own words, and ModeratorLogFactory writes one about content you already have. The history agrees with the content as it is now: an open thread was locked and then unlocked. No entry is dated in the last two hours.

Worth knowing​

• Moderator log entries are written straight into the table. Add-ons that act on a moderator action as it is taken - extending XenForo's logger, or watching each entry as it is saved - send it to a chat channel or a log. They do not see these, and seeder:run names any such add-on it finds active. The seeder is not in the sample seeder:validate uses, so validating never writes one.
• withLogin() now logs in from the member's own address, from the documentation ranges, where Beta 3 used 198.18.0.0/15.
• A parameter from this release given to Beta 3 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b4.

1.0.0 Beta 3 adds administrators, the admin log, members who hold permissions, and crawler user agents.

Nothing from Beta 2 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Administrators. admins on the User seeder makes members who are administrators, with the administrator record XenForo keeps. In a factory: UserFactory::new()->administrator(), or administrator('user', 'option') with the administrator permissions named.
• The admin log. The AdminLog seeder writes an admin log with history: a few administrators, the ordinary actions repeated and the unusual ones once. AdminLogFactory has by(), action() and from(). As with the server error log, no entry is dated in the last two hours, so nothing that reports new entries picks a seeded one up.
• Members who hold permissions. permitted and permissions on the User seeder - -p permitted=5 -p permissions=general.bypassFloodCheck,conversation.maxRecipients:50 - or UserFactory::new()->withPermissions([...]). Each member is put in an extra user group made to grant them, so they stay in Registered, and members given the same permissions share one group. A permission the forum does not have is refused, and so is a value it would not take. Another add-on's permissions work too.
• User groups. UserGroupFactory::new()->granting([...]) makes a group with the permissions it grants, written as the admin control panel writes them.
• Crawler and browser user agents. Seeders and factories now have crawlerUserAgent() (a real crawler this forum takes for a robot, the commonest most often, or one for a robot you name), browserUserAgent() (one this forum does not take for a robot) and robotFor($userAgent) on $this->context()->faker. Which agents are robots is the forum's own robot list, as other add-ons have extended it.

Worth knowing​

• Cleaning a batch with a user group in it empties the cached CSS. Deleting a user group makes XenForo mark every style as changed, as an HTML widget does, so seeder:validate makes no group. Creating one does not.
• XenForo tidies up after a deleted group, forum-wide. Once the group is gone its own job removes every permission combination no member has any more - not only the ones seeded members had.
• A parameter from this release given to Beta 2 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b3.

1.0.0 Beta 2 adds forum types, search forums, polls, sticky threads, resource discussion threads, media comments and widgets.

Nothing in Beta 1 has changed its name or its behaviour, and there is no upgrade step: upload the files and upgrade as usual.

New​

• Forums of any type. forum_type on the Thread seeder makes an article, question or suggestion forum with threads of that type, and forum_types=1 on Default makes one of each. In a factory: ForumFactory::new()->article(), question(), suggestion() or type($id).
• Search forums. The SearchForum seeder and SearchForumFactory make search forums that list the threads of the forums they are given.
• Polls. polls on the Thread seeder, or ThreadFactory::new()->withPoll($choices, $votes), makes poll threads with votes from the run's members. A new XenForo forum takes no poll threads, so ForumFactory::new()->allowing('poll') says which other thread types a forum takes. Forums the seeders make opt in when polls are asked for.
• Sticky threads. sticky on the Thread seeder.
• Resource discussion threads. discussions=1 on the Resource seeder gives each resource its discussion thread, in a forum made for them or one you name with forum.
• Media comments. comments on the Media seeder, and MediaCommentFactory.
• Widgets. The Widget seeder and WidgetFactory put widgets with a title in any widget position. Cleaning one also deletes the compiled file XenForo leaves behind when a widget is deleted.

For your own seeders and factories​

• The README now shows how to keep an attribute that is not a column between newEntity() and store(), and says that store() may hand the entity to a service of your own.
• seeder:validate counts rows, not files. A factory whose entities have files should delete them in remove(), and you should count the files before seeding and after cleaning.

Worth knowing​

• seeder:validate is not a read-only check. Where seeding is switched on it creates content and removes it again. seeder:validate --unattended and seeder:config write nothing.
• An HTML widget has a template of its own. Saving or deleting one marks every style as changed and empties the cached CSS, as editing a template in the admin control panel does. So the seeder makes none unless asked with html.
• A parameter from this release given to Beta 1 is named as ignored and the run exits 1. The README marks each new one since 1.0.0b2.