[wp-hackers] a few observations at the wp_install_defaults

[Haluk Karamete]

I would have never thought of "ever" using the wpdb->insert over the
corresponding wordpress function such as wp_insert_term, until the other
day where I saw in the core, the default installer routines chose the wpdb
route over the wp_insert. It's just a choice they made that way. It
confused me and I just wanted to double check . this issue is now over.



On Thu, Apr 12, 2012 at 8:08 AM, Brian Layman <wp-hackers at thecodecave.com>wrote:

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