タグ付けされた質問 「updating」

Drushalを介してdrupal 7.31コアを7.32に更新しようとしています。 私は次のコマンドを実行しました $ pm-releasesを削除 Project Release Date Status drupal 7.x-dev 2014-Oct-15 Development drupal 7.32 2014-Oct-15 Supported, Recommended, Security drupal 7.31 2014-Aug-06 Security 上記のコマンドの後、次を実行しました。 $ pm-update drupalを削除 Update information last refreshed: Thu, 10/16/2014 - 07:33 Name Installed Version Proposed version Message Drupal 7.31 7.31 Unknown No code updates available. だから私は次のコマンドを実行しました： …

12 drush  updating 

私のカスタムモジュールのインストールファイルには、hook_update_N関数があります。それだとしましょうmymodule_update_7100。しかし、間違っていることに気づき、この関数内のコード行を変更したいと思います。私はすでに実行してきたように見てupdb/ update.php変更がピックアップされないだろうと私はどちらかに名前を変更する必要があるだろうmymodule_update_7101か、その名前で、それの後に新しい関数を作成します。私は実際にこれを行う必要はないので、モジュールの現在の「バージョン番号」を正確にDrupalに伝える変数があるかどうか、そしてそれをリセットして更新スクリプトを実行できるようにすることができるかどうか疑問に思っていました再び。 関数がデータベースに及ぼした実際の影響は重要ではありません。それは、後でフロントエンドを介して簡単に削除できる分類用語を生成するだけだからです。

12 updating 

で新しいテーブルを作成するときhook_schema()、そのテーブルもに追加する必要がありますhook_update_N()か？または、databae-updatesが自動的にテーブルを追加するようにするためのいくつかのトリック、または私が見逃したものはありますか？ hook_update_N（）のドキュメントはhook_schema()、新しいテーブルの導入について何も説明していませんが、のドキュメントは次のように述べています： このフックによって宣言されたテーブルは、モジュールが最初に有効になったときに自動的に作成され、モジュールがアンインストールされたときに削除されます。 （ハイライトは私のものです） そうである場合、hook_update_N（）とhook_schema（）の両方で新しいテーブルのスキーマ定義が重複しないようにする方法。単にスキーマを次のように参照します。 function hook_update_N(&$sandbox) { $schema = hook_schema(); $name = "foo"; $table = $schema["foo"]; db_create_table($name, $table); } 機能しているようですが、ユーザーが更新を実行して2つ以上のhook_update_N（）を実行すると、テーブルを再度変更すると失敗します。結局のところ、最初のhook_update_Nは既に正しいデータベースをインストールしており、2番目のhook_update_M（）はすでに最新の列を追加/変更/変更しようとします。 これにどう対処しますか？

11 database  updating 

Drupal 8が導入されました。hook_post_update_NAME()これにはhook_update_n、モジュールの更新に関して、に比べていくつかの利点があります。 それぞれhook_post_update_NAME()は1回だけ実行する必要がありますが、開発中に更新フックをデバッグしているときなど、再実行したい場合があります。を使用すると、データベースのスキーマバージョンをリセットhook_update_nできます。 どのように再実行しhook_post_update_NAME()ますか？

11 8  updating 

モジュールのスキーマバージョンはKey-Valueストレージに格納されるため、各サイトに固有であり、構成管理を通じて同期されません。更新では、構成にカプセル化されていない調整（データベースの更新など）が必要になる場合がありますが、構成に含まれる可能性のあるその他の変更（新しい構成値の追加など）があるためです。 構成のインポートとデータベースの更新をどちらの順序で実行してもリスクはありますか？ これらの操作を実行するための優先順序は何ですか？ 更新フックは、すでにインポートされている可能性のある構成アイテムに対して特別な調整を行う必要がありますか？ 本番環境を完全に更新するために必要となる可能性のある他の操作はありますか？

10 8  updating  configuration-management 

具体的には、Drushに、利用可能な更新があるモジュールのうち、データベースの更新が含まれているモジュールをリストしてほしい。これはDrushで可能ですか？ 明確にするために編集：drush up利用可能な更新があるすべてのモジュールをリストすることは知っていますが、そうした更新のすべてに、それに伴うデータベース更新があるわけではありません。データベースの更新に関連付けられている更新のリストを厳密に必要としています。

10 drush  updating 

無効にしたモジュールを更新する方法はありますDrushか？ 現在、無効なモジュールをDrushで更新しようとすると、次のメッセージが表示されます。 プロジェクトには有効な拡張機能がなく、更新できません これはライブサイトであり、実際には多くのサイトであるため、モジュールを有効にすることはオプションではありません。それらはすべて同じDrupalコードベースで実行されます。一部のモジュールは一部のサイトで使用されていますが、他のモジュールでは使用されていません（メインサイトでは使用されていない可能性があります）。 Drushがこれを処理できない場合、モジュールを更新する簡単な方法は何ですか？

10 drush  multi-sites  updating 

Drupalコアを8.3に更新しようとしていますが、問題が発生しています。 ページの下部には、最初に使用するcomposer.jsonファイルがあります。 「drupal / core」：「〜8.2」=>「drupal / core」：「〜8.3」を変更して実行するcomposer update drupal/core --with-dependenciesと、次の問題が発生します。コンポーザーに含まれていないため、これを解決する方法がわかりません。以下に含めた.jsonファイル。 Your requirements could not be resolved to an installable set of packages. Problem 1 - drupal/core 8.3.0 requires symfony/psr-http-message-bridge ^1.0 -> satisfiable by symfony/psr-http-message-bridge[1.0.x-dev]. - drupal/core 8.3.x-dev requires symfony/psr-http-message-bridge ^1.0 -> satisfiable by symfony/psr-http-message-bridge[1.0.x-dev]. - drupal/core 8.4.x-dev requires symfony/psr-http-message-bridge ^1.0 …

9 8  updating  composer 

私はライブのサイトを持っていて、人々は積極的にコンテンツを入れています。ただし、開発環境に変更を加える必要があり、そのために数週間かかりました。変更により、新しいモジュールをインストールし、古いモジュールを削除する必要がありました。これにより、データベースの内容と構造が変更されました。 私の質問は、過去2週間に追加された新しいコンテンツの新しいユーザーを上書きせずに、このサイトをライブ環境にアップロードしてデータベースを更新するにはどうすればよいですか？

9 7  database  updating  migration 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 2年前休業。 私はさまざまなホスティングプロバイダーの多くのDrupal Webサイトの管理者です。 いくつかはしみがあります。他の人はしません（そしてできません：共有ホスティングのように）。 コアアップグレードがあるたびに、1〜2時間かけてすべてを更新します（アップグレード前にすべてのWebサイトのバックアップを作成します）。 Drushでサイトを更新するのは簡単ですが、次のように、すべてのWebサイトで更新する必要があります。 @devを引き上げる @othersiteを引き上げる 待って...待って...待って... コア（およびモジュール）を自動的に更新するにはどうすればよいですか。 すべてのDrushサイト？（私は思う：bashスクリプト付きのcron） すべての私のdrush以外のサイト？ これは安全ですか、それともお勧めしませんか？

9 drush  updating 

GUIで「アップデートマネージャ」を使用するときに問題が発生します。一部のディレクトリはによってロックされるphp-cgi.exeため、元のディレクトリを新しくダウンロードしたディレクトリ（新しい）で置き換えることはできません。 しかし、許可の問題ではないことに言及する必要があります。これは、モジュールが上の「URLからインストール」を介してインストールされ/admin/modules/install、問題なく動作するためです。 例を見てみましょう： 利用可能な更新ページ（/admin/reports/updates/update）： 次に、選択する（またはその他の）モジュールをチェックして更新します（どのモジュールを選択するかは関係ありません。結果は同じです!!したがって、例にすぎません）。 私はヒット「これらの更新プログラムをダウンロードする」ボタンを押します。 OK、モジュールの更新されたインスタンスは問題なくダウンロードされます： 「更新が正常にダウンロードされました」： 次に、[ 続行 ]をクリックします。 ここでエラーが発生します。結果： 「更新に失敗しました。詳細については、以下のログを参照してください 。select_or_other インストール/更新エラー ファイル転送は、その理由を失敗しました：コピーできませんD:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txtし/Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt。」 はい、考えられる理由を調べようとしています。 Drupalのディレクトリ構造は次のようになります。../tmp一時ディレクトリ（/admin/config/media/file-system）に設定すると、Drupalファイルはにありhtdocsます。上記で述べたように、GUI経由でモジュールをインストールできるため、これは正しいです。 htdocs/sites/all/modules/select_or_otherディレクトリにアクセス......sites/all/modules/select_or_otherしようとすると、「ファイルへのアクセスが拒否されました！」というメッセージが表示されるため、アクセスできません。総司令官で開いたとき、および「...sites/all/modules/select_or_otherアクセスできませんアクセスが拒否されました。」ときに、Windowsエクスプローラで開きます： 、 OK、フォルダを右クリックして、コンテキストメニューのアシスタントからUnlockerを開きます。それはこのディレクトリがロックされていると言い ますphp-cgi.exe： 「すべてをロック解除」をクリックすると、フォルダはそれ自体を削除できます（によってロックされなくなったphp-cgi.exeため）。 更新されたselect_or_otherモジュールのディレクトリはtmp次の場所にあります： 手動でsites/all/modulesディレクトリに移動する必要があります。 によるディレクトリのロックアップの考えられる理由は何php-cgi.exeですか？（たぶん、Webプラットフォームインストーラーを介してインストールされたPHP 5.3用のWindowsキャッシュ拡張1.1ですか？そうであれば、たとえば、GUIを介した画像の削除などが正しく機能しているのはなぜですか？）この問題を回避するには、どうすればよいですか。 マネージャー」の仕事？

9 7  iis  updating 

単純なHTTPプロキシの背後にあるイントラネットでDrupalを実行しています。モジュールとコアの更新チェックが実際に機能するようにしたいと思います。 Drupal 6でこれを行うためのコアハックがあったことを覚えているようですが、ページが見つかりません。 誰かがこれをどのように機能させることができるか知っていますか？

9 6  updating  proxies 

カスタムモジュールの更新を提供したいと考えています。これには、を介して提供されるいくつかのルールもありますhook_default_rules_configuration。 これらの既存のルールを更新するにはどうすればよいですか？再インポートできますか？どういうわけかそれらをオーバーライドしますか？ドキュメンタリーまたはそれぞれのフックでこれについて何も見つけることができません。 更新されているルールに応答するためのフックがあるようですので、カスタムルールの更新を提供する方法が必要だと思います... 最初はhook_default_rules_configuration_alterだと思っていましたが、JSONをインポートしたいだけなので、期待どおりに動作しないようです。 たとえば、ビューを使用.incするとviews_save_view 、この質問のようにすべてのファイルをロードして保存できます-ルールに同様の方法はありませんか？

8 7  rules  updating  importing-exporting 

コマンドでdrush up、drushを使用して更新しようとしていますが、コアが更新されていません。それはdrush出力について述べています： Project drupal was updated successfully. Installed version is now 7.27. しかし、そうではありません！ステータスレポートは、バージョンがまだ7.26であることを明確に示しています。また、drushを再度実行してみたところ、実行するたびに正常に26から27に更新されました... 更新 私はこのコマンドをしました： drush up drupal -v そしてこれは出力でした： Initialized Drupal 7.26 root directory at /www/permalink.hashworld.co/docs [notice] Initialized Drupal site default at sites/default [notice] Loading release_info engine. [notice] Loading version_control engine. [notice] Loading package_handler engine. [notice] Executing: wget --version …

8 7  drush  updating 

コントリビュートされたモジュールに新しいバージョンがある場合は常に、Drupalのアップデートマネージャーは通知を表示し、アップデートの自動ダウンロードを許可します。その後、ユーザーは「update.php」を案内されます。カスタムモジュールに対して同じ自動処理を取得することは可能ですか？ 特定のサイト用にいくつかのカスタムモジュールを開発する場合、自分でモジュールをホストしている指定のサーバー上で、Drupalに上記のカスタムモジュールの更新を検索させ、提供されたものと同様に扱うのは興味深いことです。モジュール。しかし、これは良い習慣に反するのでしょうか？

7 7  updating