[wp-hackers] a few observations at the wp_install_defaults

[Brian Layman]

The con of using wpdb->insert over wp_insert_post is that you give up 
any future compatibility efforts, any data filters or action handlers 
that are put in place by plugins and/or themes and you would possibly 
avoid security methods that are built into the insert.

Brian Layman

On 4/12/2012 9:07 AM, Otto wrote:
> No, and you should use the specific functions of wp_insert_post and so forth.
>
> -Otto
>
>
>
> On Wed, Apr 11, 2012 at 2:13 PM, Haluk Karamete<halukkaramete at gmail.com>  wrote:
>> Otto,
>>
>> When adding posts programmatically, is there any advantage of using
>> wpdb->insert over the wp-insert_post?
>> And the same question goes for inserting links or comments. Do you guys
>> suggest to use wp_insert_link and wo_insert_comments? Are there any con's
>> that I should be aware of?
>>
>>> 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.
>>
>> 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
>>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers