• DONATE to NULLED!
    Вы можете помочь Форуму и команде, поддержать финансово.
    starwanderer - модератор этого раздела будет Вам благодарен!

Вопрос Скрипт пакетной установки

Статус
В этой теме нельзя размещать новые ответы.

Grafs

Постоялец
Регистрация
19 Дек 2008
Сообщения
74
Реакции
12
Вот стала такая задача. Нужен скрипт который бы:
1. Залив на хост зип архив блога распаковал его в указанную директорию
2. В архиве есть дамп базы с всеми настройками блога, нужно чтобы скрипт изменил в дампе пути на пути этого хоста
3. Востановить дамп из базы
4. Удалить первый архивный файл
5. Важно чтобы он умел это все делать и в обратном порядке с п.3 по п.1

Может есть у кого уже собственные решения, поделитесь
 
Вот что раскопал случайно - пробуйте =)

Код:
[B][COLOR=#0b6d90]Automating WordPress customizations - the install.php way[/COLOR][/B]
 
Posted by [B][COLOR=#0b6d90]Leonid Mamchenkov[/COLOR][/B] on August 10, 2007
In “[B][COLOR=#0b6d90]Automating WordPress customizations - the plugin way[/COLOR][/B]” we looked at how to change a whole bunch of thing in one go by having our own plugin.  The plugin approach can save a lot of time, but it does not actually give any control over the installation process.
Often we want to interfere with the way things are.  For example, upon successful WordPress installation you find a web site with one post (”Hello World!”), one page (”About”), and a test comment to the first post.  Also, there is a category “Uncategorized”, and “admin” user, and a few other things in the database, which are not so obvious (for example, user roles, such as Administrator, Editor, and Subscriber).
There are also a few things, which are happening during the installation process itself.  For example, a random password for the administrator is generation, and email is sent to the administrator’s address with credentials and new site details.  As handy as it is for a friend’s new blog, there are many situations when we don’t want this done, or want it done differently.
WordPress has a way to control installation flow via a custom [I]install.php[/I] file, which saves you from all the problems of core files editing.  In this post, we’ll see how to use this feature and what can actually be done with it.
 
Let’s start with some source diving.  Before we do any modifications of our own, it’s good to get an idea of how things work under the hood.   The installation process starts with [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Finstall.php.source.html"][B][COLOR=#0b6d90]wp-admin/install.php[/COLOR][/B][/URL] , so this where we’ll start too.  This is what we see at the top of the file (chopped off on the right a bit, but it doesn’t matter for now):
[IMG]http://wpbits.files.wordpress.com/2007/08/top_of_install_php.png[/IMG]
A flag that signals that we are in the installation process is set, and a check is done for the presence of the [I]wp-config.php[/I] file, which should have database credentials, table prefix, and things like that.  So far so good.
Then the content of [I]wp-config.php[/I] is imported.  OK, makes sense.
Then the content of [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Fupgrade-functions.php.source.html"][B][COLOR=#0b6d90]upgrade-functions.php[/COLOR][/B][/URL] is imported.  Hold on. What’s that?  Let’s see the content of that file before we go forward.  Maybe there is something interesting in there.  Here are the first few lines:
[IMG]http://wpbits.files.wordpress.com/2007/08/top_of_upgrade-functions_php.png[/IMG]
A check is done for the presence of [I]wp-content/install.php[/I] file.  And if it exists, it’s included straight away.  But what is in this wp-content/install.php file?  I don’t have any in my brand new and shiny WordPress installation.  Did I do something wrong?
No!  This is exactly what we were looking for.  This is the way WordPress gives you all the power over the installation process.  Before it does anything itself, it checks if instructed it to do anything.  If you don’t have your own [I]wp-content/install.php[/I] file, WordPress will do its own installation routine.
What can we do with it now?  Anything.  But anything is too broad of a thing.  We need a test of our new superpowers.  How about we cancel a WordPress installation altogether?  That should prove how much power we have over WordPress.  So, here is the content of [B]the first version[/B] of my [I]wp-content/install.php[/I] file:
[IMG]http://wpbits.files.wordpress.com/2007/08/custom_install_php_v1.png[/IMG]
Looks sufficient.  Now let’s see what happens to the installation process… Oh, Noooo! It didn’t work!  It worked, but it didn’t do everything I wanted it to.  Here is how my WordPress installation screen looks now.
[IMG]http://wpbits.files.wordpress.com/2007/08/broken_wordpress_installation_v1.png[/IMG]
My evil signature appears at the top of the installation screen, but the installation didn’t stop.  Why? Because, actually I never told it to.  So, here is the second version of my custom install.php, which should fix the problem:
[IMG]http://wpbits.files.wordpress.com/2007/08/custom_install_php_v2.png[/IMG]
Now I tell WordPress to exit (as in finish, stop, end) from the installation process, like everything is done.  And it works!  Here is how my installation screen looks now:
[IMG]http://wpbits.files.wordpress.com/2007/08/broken_wordpress_installation_v2.png[/IMG]
So, now there is no way to install WordPress.  I have full control over the matter.  And that makes me feel all that powerful and important. Now that we established the authority (”Respect my authorita!” © South Park), how can we do good?
Although you can completely re-write and re-implement WordPress installation process, it’s not something you’d want to do very often.  After all, it works, right?  So, why break it?  What we do want often though is some minor changes to the process.
How can we achieve this?  Is there a simple way of modifying WordPress installation without creating it from scratch ourselves?  The answer is - yes.
Let’s look further down into the [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Fupgrade-functions.php.source.html"][B][COLOR=#0b6d90]wp-admin/upgrade-functions.php[/COLOR][/B][/URL] file.  It has functions, alright.  But there are a few places where it checks for the presence of the function, before defining it.  See the example of [I]wp_install()[/I].
[IMG]http://wpbits.files.wordpress.com/2007/08/middle_of_upgrade-functions_php.png[/IMG]
Notice that [I]function_exists(’wp_install’)[/I] check?  Why is it there?  Doesn’t WordPress know which functions it has and which it doesn’t?
 

This is the nice way that WordPress gives us to control the installation process without much work on our side.  If we look through the file, we’d notice that there are four functions which are defined in this way:
[LIST]
[*][I]wp_install()[/I]
[*][I]wp_install_defaults()[/I]
[*][I]wp_new_blog_notification()[/I]
[*][I]wp_upgrade()[/I]
[/LIST]So, these are the places where we can easily interfere.
Since we only want to change just a few things, we can start from the existing code.  We can achieve that by simply copying the code from WordPress definitions of these functions into our custom [I]install.php[/I] and change a few lines there.  If we have any of those functions defined in our [I]install.php[/I], WordPress will use those instead of its own ones.
[B]IMPORTANT:[/B] if we are to supply WordPress with our own functions, than we should accept the parameters and return values as WordPress expects them.  Otherwise, things might break.
So, what do those special functions do?
[B]wp_install()[/B]
This function handles the installation routines.  It calls other methods, which create database tables, populate options with default values, create user roles, etc.  It also creates an admin user with a random password and assigns it an Administrator  role.  Once everything is done, it calls another function to send a notification about successful blog installation.
[B]wp_install_defaults()[/B]
This function creates all those default entries that you find in your new WordPress installation - first post, first comment, first page, default category, and a bunch of links in the blogroll.
[B]wp_new_blog_notification()[/B]
This function generates and sends that email with username and password which site administrator gets upon a successful installation.
[B]wp_upgrade()[/B]
This function handles the upgrade process.  If you made a lot of changes to the installation process, chances are you’ll want to make sure those changse are handled properly during the upgrade of the system, and so this is the function to help you out in that.
Here are a couple of examples of what you might want to do.
[B]Modify user roles[/B]
If you want your web sites roles to be configured differently, you can, of course, use an excellent Role Manager plugin and set them just the way you want.  But that would be a pain to do over and over again for new sites.  So, it might be a better option to customize things automatically during the installation process.
 

Here is how to do that:[LIST=1]
[*]See how [I]populate_roles()[/I] function works (it is defined in [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Fupgrade-schema.php.source.html"][B][COLOR=#0b6d90]wp-admin/upgrade-schema.php[/COLOR][/B][/URL] file)
[*]Define your own function (say [I]populate_my_roles()[/I]) in your custom [I]install.php[/I]
[*]Copy the definition of [I]wp_install()[/I] function from [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Fupgrade-functions.php.source.html"][B][COLOR=#0b6d90]wp-admin/upgrade-functions.php[/COLOR][/B][/URL] into your custom [I]install.php[/I]
[*]Add a call to your role functions ([I]populate_my_roles()[/I]) after the call to [I]populate_roles()[/I] in the copied [I]wp_install()[/I] function.
[/LIST][B]Add, change or remove default category, post, page, links[/B]
I’ve heard many people who want to start with “General” category, not “Uncategorized”.  And if you are making lots of WordPress-based web sites, than first post, page, and comment probably don’t make much sense - you remove them right after the installation.  If you are WordPress installations for corporate clients, you often want to lose the default links (as much as you love WordPress developers, links to their blogs don’t make much sense from your clients’ web sites).
[I]wp_install_defaults()[/I] is the place to do all that.   Copy it to your custom install.php .  If you want to start with a clean WordPress installation - remove all lines in that function.  Just delete them.  So that you have only the function definition and nothing else.  Otherwise, add and edit the lines accordingly.  Most of the stuff you see in WordPress’ function definition are SQL statements anyway.  So you can put your own ones here.
Now it is time to return to the [URL="http://www.nulled.ws/r.php?url=http%3A%2F%2Fwordpress.taragana.net%2Fwp-admin%2Finstall.php.source.html"][B][COLOR=#0b6d90]wp-admin/install.php[/COLOR][/B][/URL] file, which we got carried away from by all those upgrade functions.  If you scroll through really slow, you’d notice that there is something about steps in there.
[IMG]http://wpbits.files.wordpress.com/2007/08/installation_steps.png[/IMG]
These steps are used to move the user from one installation screen to another.  In the same file, there is a switch() statement, which selects the appropriate screen to show.  There are a few links and forms in the file, that specify to which step the installation should switch further.  Those a bit difficult to spot because of all the HTML markup in the file, but you can search for “step” and see where it is used.
The [I]install.php[/I] file from WordPress can be used as a real example for a custom installation routine.   If you want to change the way your WordPress is installed, what the user is asked, or which functions are called at which points of the installation, [I]install.php[/I] is a valuable reference.
Did I miss anything?

Оригинал взят отсюда

И Пакетный способ =)

Код:
[B][URL="http://wpbits.wordpress.com/2007/08/09/automating-wordpress-customizations-the-plugin-way/"][COLOR=#0b6d90]Automating WordPress customizations - the plugin way[/COLOR][/URL][/B]

Posted by [URL="http://mamchenkov.net/"][B][COLOR=#0b6d90]Leonid Mamchenkov[/COLOR][/B][/URL] on August 9, 2007
If you installed WordPress more than two times, you know the drill. [URL="http://wordpress.org/download/"][B][COLOR=#0b6d90]Download the latest version[/COLOR][/B][/URL], unzip or untar, copy [I]config-sample.php[/I] into [I]config.php[/I], edit [I]config.php[/I], upload files to your web host, visit new WordPress URL, click “[I]Next Step[/I]” a couple of times, while submitting blog name and administrator’s email. After all is done, login with username “[I]admin[/I]” and provided random password, go to [I]Options[/I] menu, and set things the way you want them to be. Then upload and activate chosen plugins, and then switch theme to something you’ve spent some time searching for or designing.
Overall, the process is very simple and straight forward. And there are rumors that it will be even simpler in upcoming versions of WordPress. It’s all nice and good. But there is something that only you can make better.
If you installed WordPress more than two times, and by now we know you did, chances are you have a certain way of configuring things. You probably use the same administrator’s email. Or want to use a pre-defined password, not a randomly generated one, because you seriously can’t remember random passwords for those 20 test WordPress installations just on your laptop. Now, going through [I]Options[/I], setting things the same every time is boring.
There are, of course, better ways. In this post we’ll see how to automate this task with a plugin. In one of the near future posts we’ll see how to do even better with a custom [I]install.php[/I] file.

To get a few ideas for a starting point, let’s look at what WordPress does itself. It uses some defaults for sure, as there are many things that we don’t need to change when we login for the first time. Yes, those are called reasonable defaults, and WordPress has them specified somewhere. Let’s look.
I’ll save you some source code digging and tell you where the yummy stuff is. SQL scheme and default options are in [URL="http://wordpress.taragana.net/wp-admin/upgrade-schema.php.source.html"][B][COLOR=#0b6d90]wp-admin/upgrade-scheme.php[/COLOR][/B][/URL] file, and some initial records, like first post, first page, first comment, and default blogroll are done from [URL="http://wordpress.taragana.net/wp-admin/upgrade-functions.php.source.html"][B][COLOR=#0b6d90]wp-admin/upgrade-functions.php[/COLOR][/B][/URL] .
So, now that we know what WordPress sets for it’s defaults, we have an idea of what we want to change. Let’s pick something simple, just for the sake of the example. Say, I want to use 20 items in RSS by default, not 10. And I want to disable smilies, because most of my WordPress installations are for corporate clients with very little sense of humor. The options I am therefor interested in are ‘[I]posts_per_rss[/I]‘ and ‘[I]use_smilies[/I]‘. I want to set 20 for the first one, and 0 for the second one.
It’s time to write my plugin. Here is [B]the first version[/B], as small and simple as I cared to make it:
[IMG]http://wpbits.files.wordpress.com/2007/08/local_settings_plugin_v1.png[/IMG]
I save this code into [I]local_settings.php[/I] file and upload it to [I]wp-content/plugins/[/I] folder. Now I can see a new plugin entry in the Plugins management.
Before I activate my plugin, I want to see the old values. I check the [I]Options->Reading[/I] screen and see that [I]Syndicated Feeds -> Show the most entries[/I] is set to 10, as in all WordPress installations by default. I also make a test post with a smily in it and check that the smily image in fact appears on my new WordPress front page. And just to be absolutely sure, I look through [URL="http://wpbits.wordpress.com/2007/08/07/quick-access-to-wordpress-options/"][B][COLOR=#0b6d90]all options quickly[/COLOR][/B][/URL] for the values that I’m interested in. Everything is right - default WordPress stuff.
Now I [I]Activate[/I] my plugin and rush back to [I]Options->Reading[/I] to see the changes. Hooray! The number of items in my RSS feed is set to 20 now. Reload the front page, and I don’t see the smily anymore. It’s pure ASCII stuff - columns and brackets. Quick list of options confirmed that the default WordPress values are now in fact my default values.
A quick beer to celebrate the victory and and a new skill in my toolbox. But wait.. what’s that? Hold on! Oh, no! It seems that I can’t change my default values to anything else now…
I do want to have my own defaults, yes. But I want to be able to change them on those sites that need changes. Like with WordPress values - I can change all the defaults I want. Now, whenever I change the number of RSS items in [I]Options->Reading[/I] screen and save a new value, it seems to have no effect. My default of 20 items comes back no matter what I do.
The good thing is that I just started my celebrations, and my mind is still sober. I am quickly enlightened to the fact that those two lines in my plugin are executed on every WordPress page load. I specified no conditions at all.
It’s time for the second version of my plugin. This time, I want those lines to execute only once, when my plugin is activated. How do I tell WordPress to execute those lines at specific moment in time? I need a hook. A quick look at [URL="http://codex.wordpress.org/Plugin_API"][B][COLOR=#0b6d90]Plugin API[/COLOR][/B][/URL] and [URL="http://wphooks.flatearth.org/"][B][COLOR=#0b6d90]WordPress Hooks[/COLOR][/B][/URL] sorts me out. It turns out, I am looking for [URL="http://wphooks.flatearth.org/hooks/activate_plugin-filename/"][B][COLOR=#0b6d90]register_activation_hook()[/COLOR][/B][/URL] function. So, here is [B]the second version[/B] of my plugin:
[IMG]http://wpbits.files.wordpress.com/2007/08/local_settings_plugin_v2.png[/IMG]
What’s happening here? Nothing much. I put all my options in a function. And then I told WordPress to call this function every time a plugin in the current file is activated.
A test is in order. I go to my Plugins management and disable the old version. Now I go to [I]Options->Reading[/I] and change my default value back to WordPress default value of 10. Save it and make sure that it works. It does (because my super plugin is disabled and does not interfere with the balance of nature). Now I upload the new version of my plugin, go back to Plugins screen and Activate it. A quick check with [I]Options->Reading[/I] confirms that the value of RSS feeds was set to my default of 20. And I can change it now too. The smily test is also passed and I’m smiling too over a new bottle of beer.
While I enjoy my pint, I have a couple of small ideas on how to improve my plugin. First of all, I want to set default WordPress values back when my plugin is deactivated. This seems like a proper line of behavior. So, here is [B]the third version[/B] of my plugin, which adds this important functionality:
[IMG]http://wpbits.files.wordpress.com/2007/08/local_settings_plugin_v3.png[/IMG]
For any action there is a reaction. For any activation there is a deactivation. I don’t even have to dig through the documentation anymore. I’m assuming some things exist, and they in fact do. This is one of the reasons I love WordPress so much.
Another round of tests shows that everything works OK. I’m proud enough to show this little thing to one of my co-workers, who immediately spots the problem. You see, this is why you should stick to open source code as much as possible, and show your code to as many people as possible. It’s just so much easier to make your code better this way.
The problem my co-worker noticed is with going back to WordPress defaults. It is true, WordPress sets those values that I use as initial defaults. But those values aren’t necessarily the same when my plugin is activated. So, instead of going back to initial WordPress values, I should return to values which were set before my plugin was activated. To do so, I have to save those values before I overwrite them.
Here comes [B]the fourth version[/B] (and final for now) of my plugin:
[IMG]http://wpbits.files.wordpress.com/2007/08/local_settings_plugin_v42.png[/IMG]
Whoa! It’s a long one! But I’m just building on the previous versions here. I get the values of the options before I overwrite them with mine. I save them into two other options (’[I]orig_posts_per_rss[/I]‘ and ‘[I]orig_use_smilies[/I]‘). When my plugin is deactivated, I revert the changes. And, being a good WordPress citizen that I am, I delete the unused options.
While testing the plugin, the [URL="http://wpbits.wordpress.com/2007/08/07/quick-access-to-wordpress-options/"][B][COLOR=#0b6d90]quick access to WordPress options[/COLOR][/B][/URL] tip comes handy. When my plugin is activated, I can see the extra options in the list of all options, although there is no direct user interface to edit those options. When my plugin is deactivated, I can make sure that the unused options are deleted.
[IMG]http://wpbits.files.wordpress.com/2007/08/saved_original_options.png[/IMG]
Here, you have it. A quick and easy way to customize WordPress installations without doing lots of boring manual work and without modifying any internals. Next time we’ll see a totally different approach to this problem - a customized [I]install.php[/I] file. If you are in a hurry, you can find all about it yourself. I gave you all the hints already.
 
Xp10r3r, ты сам попробовал? )

UPD почитал, но мне не хватило чето в мозгу, что бы понять - это "ОНО" или не "оно" )
Не пробовал - времени не хватает этим заняться, а надо искать нормальный способ...

Ссылку на первоисточник дал, чтобы разобраться "оно" или нет =)
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху