You should be able to do all of this from a plugin by hooking into these two events :-

				'AdminDisplayBlogSettingsForm' => 'This gets called when the blog settings are displayed.',
				'AdminBeforeBlogSettingsFormInsert' => 'This gets called before the blog settings get updated.',

¥

Pardon me Yabba, what is got to do with plugin? And which file has the code you mentioned.

I simply want to save afield called dsplay_order which is the general setting of each blog.

Plugins are the new way forward.

If you coded one to use those two hooks then you could add your field and store the results without hacking any of the core files (which makes things 100% easier if you ever upgrade)

¥

My intended purpose is to make this a hack available to everyone, but as you said it means hacking some core files.

Of course I would prefer to do it as a plugin but I don't know how.

If you could tell me for now where is that save code is just get me through untill I can code it as plugin, I would really appreciate it.

The save code is (probably) found in inc/controls/collections/blogs.php

You should have a play with some of the existing plugins though, you'd be amazed how many hacks you no longer need ;)

¥

Sorry if i sound like an idiot but I found in

inc/controls/collections/blogs.php

create, copy and so on but there is no mention of the parameters that should be added, updated and so on.

Depending on which tab you've added your field to, you'd need to amend one of these ( beofre the relevant $edited_Blog->dbupdate() call )

	case 'update':
		// Update DB:
		// Check permissions:
		$current_User->check_perm( 'blog_properties', 'edit', true, $blog );

		switch( $tab )
		{
			case 'general':
			case 'display':
				if( $edited_Blog->load_from_Request( array() ) )
				{ // Commit update to the DB:
					$edited_Blog->dbupdate();
					$Messages->add( T_('The blog settings have been updated.'), 'success' );
				}
				break;

			case 'skin':
				if( $edited_Blog->load_from_Request( array() ) )
				{ // Commit update to the DB:
					$edited_Blog->dbupdate();
					$Messages->add( T_('The blog skin selection has been updated.'), 'success' );
				}
				break;

			case 'advanced':
				if( $edited_Blog->load_from_Request( array( 'pings' ) ) )
				{ // Commit update to the DB:
					$edited_Blog->dbupdate();
					$Messages->add( T_('The blog settings have been updated.'), 'success' );
				}
				break;

This really would be 100% easier as a plugin though

¥

I assume this code should update what is in the form without specifying the individual parameters. I added that field th the form and it get the correct value but it does not update or save when I create new blog.

Here's a possible solution for you (if you don't use your blog shortnames)

Change your shortnames to ##shortname where ## is the "position" you want them shown in. Then crack open skins/<skin name>/_bloglist.php and ammend the following lines :-

/* there's two lines like this */
		$blog_link .= format_to_output( blog_list_iteminfo( 'name',  false ), 'htmlbody' );

/* there's one line like this */
	$blog_links[ strtolower( blog_list_iteminfo( 'shortname', false ) ) ] = $blog_link;

/* add this line in just above the "output" comment as shown */
ksort( $blog_links );
// Output:

¥

I use the short name. I think since the field I added in showing in the general form with the correct value for each blog, it would be simpler to just update when changed.

I used that hack with version .9.2 and it works just fine but I forgot how to that part (Save part)

The "save" part is in the code I posted above. If you really wanted to hack the core then you might be better diving into inc/model/collections/_blog.class.php and changing function load_from_Request() to include your new field as it'd (probably) cover create & update.

Alternatively, you could still use the shortname as I mentioned just change this bit ( in both places ) :-

/* lets strip of the two ##'s */
$blog_link .= format_to_output( substr( blog_list_iteminfo( 'name',  false ), 2 ), 'htmlbody' );

¥

What I want is exactly this function

if( $edited_Blog->load_from_Request( array() ) )

¥åßßå wrote:

If you really wanted to hack the core then you might be better diving into inc/model/collections/_blog.class.php and changing function load_from_Request() to include your new field

It's in that file somewhere (you should just be able to do a search to find exactly where) ;)

¥

I used to do that when I used windows, but now I use MAC and there no such command to search for text inside folders and files.

I guess I just have to keep search file by file.

It's on line 189 in that file???

	/**
	 * Load data from Request form fields.
	 *
	 * @param array groups of params to load
	 * @return boolean true if loaded data seems valid.
	 */
	function load_from_Request( $groups = array() )
	{

¥

I'm using 1.9.2 and that function is not in that file. Actually there is no function of any kind in that file.

I'm assuming you're in the wrong file ???

¥

You're right I was looking at the wrong file. But when I added this line, the last line of two below, nothing change, i.e. it won't save the change.

$this->set( 'locale',        $Request->param( 'blog_locale',        'string', $default_locale ) );
			$this->set( 'disp_order',        $Request->param( 'blog_disp_order',        'integer', $default_disp_order ) );

Hmmmm, I'd have to take a tad of a deeper root into the core to be able to solve this.

You really would be better off trying to move it to a plugin though, that way it'd make your next upgrade far less painful.

¥

What is the best way to learn how to write plugin?

Now that's IS a tough question.

You'd probably be best off starting with a plugin that does something like what you want and then tearing it to pieces and seeing "how" it does it (not neccessarily a plugin that does this particular task).

Then leap into inc/misc/_plugin.class.php and inc/misc/_plugins.class.php to see just "what" they can handle.

Then hit your text editor and start breaking things ;)

¥

You are referring to the same file twice.

Actually, one is "plugin" and one is "plugins". I see both in my install, though I don't really know what the difference is between them.

The plugin class is the "parent" of each plugin and shows what they can handle

The plugins class is a collection of every plugin and (sorta) handles what they can do

¥