[wp-hackers] a few observations at the wp_install_defaults

Haluk Karamete halukkaramete at gmail.com
Tue Apr 10 17:01:34 UTC 2012


Well said. No objections. I'm moving on.

On Tue, Apr 10, 2012 at 9:10 AM, Otto <otto at ottodestruct.com> wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


More information about the wp-hackers mailing list