[wp-hackers] a few observations at the wp_install_defaults

[Otto]

On Tue, Apr 10, 2012 at 5:19 AM, Haluk Karamete <halukkaramete at gmail.com> wrote:
> does not use wp-insert_term. instead, it uses wpdb->insert style.

It's an installation process. It's not "inserting terms", it's
inserting rows into the database tables.


> though, wp_terms mysq table's ID field is set up to be auto-incrementing
> from the get-go, yet, wp_install_defaults prefers to set the cat_id to 1 (
> for the first cat term added that is "uncategorized ). A similar situation
> occurs where "blogroll_id is hard coded in code to be as 2 before it is
> used in its related wpdb->insert call.

Yes, because those are the first terms added to the table, so their
state is a known starting state. It really doesn't matter whether
they're set by an auto-increment process or not, however because the
state of the table is known and the IDs are assuming in other places
by other rows, they need to be set precisely instead of having an
assumption made about the starting state of the auto_increment field.



> for the "first post", the guid is prepared to be as follows;
>
> $first_post_guid = get_option('home') . '/?p=1';
>
> Now, when I add posts programmatically, what am I going to with this guid
> field? Do I randomly come up with id's? I would be using permalinks at the
> end of the day, so that does this guid field p= value matter at all? can I
> just keep it as blank?

The GUID field is added programmatically. You don't set it at all if
you use wp_insert_post and the like. However, choosing a random ID
would be incorrect, the ID is the ID of the post. Ideally, you
wouldn't ever choose this in the first place.


The installation process is setting the database to a known initial
state. It's setting up things to be correct. It bypasses some of the
normal automatic processes to do this. This is not unusual, since the
state of a blank WP database is known in advance.


-Otto