フォーラムへの返信

15件の返信を表示中 - 46 - 60件目 (全226件中)
  • フォーラム: 使い方全般
    返信が含まれるトピック: プラグイン等がインストールできません。

    パーミットディナイはコードの書き損じでも出ます。
    いろいろ試行錯誤して、という作業の中に書き損じがなかったでしょうか。
    一旦変更点を全部元に戻せるでしょうか。
    書き込む作業と戻す作業が反復できれば、技術はいくらでも向上します。
    まずは正常な状態に引き戻せるかお試しになられてはいかがでしょうか。

    プラグインはご利用のプランで適合していないため不可能であることで決着でしたでしょうか。
    いずれにしましても、プラグインとご利用のサーバープランについて解決されていましたら、次の取り組みに進まれてはいかがでしょうか。

    フォーラム: プラグイン
    返信が含まれるトピック: WooCommerceのWP メモリー制限について

    具体的な数値がはいっているのでなにかの設定で試算されたものかと思うのですが、PHPとしては128Mで機能していると思います。

    制限をうける箇所、メッセージがでる原因は

    ・htaccess
    ・WooCommerce稼働前のなんらかのPHPプログラム
    ・ワードプレスのメモリ設定はphp.iniを凌駕しなので、オーバーした時点でテンプレートを返す

    などではないかと思います。
    PHP構文内でini_setなどを使ってメモリを再定義しているところはないか、htaccessにて記述がされているものがないか確認してゆく作業が必要かなと思いました。
    WooCommerce機能稼働より後にメモリが128であることが確認できたとすれば、また別の問題かもしれないと思います。
    メモリを制限する必要性がでてくるのは複数のドメインをレンタルホストで動かしたりする場合だと思いますので、マルチサイト等、アクセス経路を複数担う系統のプラグインなどありましたらご確認されてみてはいかがでしょうか。

    もしかエラーで定型文が表示されているだけで数値的には実態を伴わないのであえば、128M内の算出、動作誤差に安全マージンを設けて、ワードプレスの設定上限を120Mなどとしてみてはいかがでしょうか。

    フォーラム: 使い方全般
    返信が含まれるトピック: トップページに抜粋表示するカスタマイズ

    当該記事のコメントを許可しないよう設定をすれば、消えませんか?

    フォーラム: プラグイン
    返信が含まれるトピック: WooCommerceのWP メモリー制限について

    ワードプレスでのメモリ確保はphp.iniを凌駕しないようなので、一度こちらで確保されているメモリの容量をご確認されてみてはいかがでしょうか。

    echo ini_get('memory_limit');

    こちらでもし容量が小さくなっていた場合、php.iniの設定またはサーバーのコントロールパネルで設定されると十分につかうことができると思います。
    もし答えが-1であれば設定がないので搭載分だけ全部利用することができる設定だと思います。

    • この返信は7年、 8ヶ月前にmsioが編集しました。理由: すみませんカッコがだめな感じになってました。

    お使いのサイトにログインされコントロールパネルから外観の項目のなかに「テーマの編集」という項目がありますので、そちらを選択されるとお使いのテーマの仕様が各種ございますので

    その中から、「テーマヘッダー」という項目を選択すると直接書き込むことができます。
    一般的なHTMLの書式で<head> </head>タグの中に追記されるとよいと思います。

    フォーラム: テーマ
    返信が含まれるトピック: フロントページが投稿ページみたいになる

    本来、というあるべきフロントページがどのような形であるかお教えいただけると解決の方法をお持ちのユーザーさまは多くおられると思います。
    フロントページはどうあるべきと構想をお持ちかご説明をいただけると幸いです。

    js、CSSファイルならばlinkタグで読み込むことができると思います。
    パスの指定を正しく行えばできると思いますが、表示されているURLからのパスにになりますので若干くせがありますがお試しいただくうちに簡単に理解できるものだと思います。
    読み込み位置は動的でなければどこに書いてもだいたい動きますので、記事本文中に書かれても大丈夫かと思います。
    一般のHTMLページに記載の例をコピーしてはりつけて実現できると思います。

    7の導入になられていたのですね。
    結果を拝見しましてインストールはなされていると思います。
    次はPHPからそのモジュールが参照できているか、確認いただければと思います。
    いずれも動作を確認できれば次はサーバーのセッティング、書き込み顕現やディレクトリの設定などになるかと思います。
    テストコードがあればなにより早いかと思うのですが持ち合わせがなく私が申し上げることができるのはここまでだと思います、
    陰ながら解決をお祈りいたしております。

    モジュールのインストール、アンインストールについて正しく動作が完了しているのでしょうか。
    grep gd などで関連付けはご確認されているでしょうか。
    パネル上では完了とでていても実際にはエラーで終わっており表示上だけ「インストール(という作業だけは)完了しました」となっている可能性はないでしょうか。
    yum でEオプションでもノード削除でも消せないとなるとインスタンスが作成されていないのではないかと思います。
    yumのListにインストール履歴はあるでしょうか。
    履歴があればリポジトリ依存のプロファイルなどにコピーされてしまっている等ないでしょうか。
    gdを利用なされるのにまずインストールの状況と状態のご確認、GD自体の稼働状態もあわせて確認いただけると幸いです。
    インストーラー的には「ない」と出ているようなのでインストールされていないまたはただのコピーファイルがディレクトリにあるかではと思いますがいかがでしょうか。
    インストーラは終わっているのに、という問題についてはままあることなのでエラーログやパッケージの展開を確認されて正しく完了しているかご確認されてみてはいかがでしょうか。
    環境設定については限りがないので専門の方と多くを取り組まれることがこちらでのやりとりより良いかと思います。
    同じ状況の経験者さまがいらっしゃいましたら、お目にとどまれることをお祈りいたしております。

    サイズ違いの画像が作成されない件について画像加工用のライブラリがPHPにおいて機能していない問題の解決について、 @ishitaka さまのおすすめされているものを含め、フォルダの権限、機能設定のご確認などいただいたうえで先のGDインストールがはかどらない場合、レンタルサーバーにOS設定選択をなされたのであれば準備環境にGDI+がご利用になれる可能性もあると思うので、環境に適合したサムネイル作成プラグインなどの導入も検討されてみてはいかがでしょうか。
    WebサーバーサービスやJavaでも画像は加工できますので、もしかすると独立して稼働するプラグインがあるかもしれません。
    ご検討くださいませ。

    • この返信は7年、 8ヶ月前にmsioが編集しました。理由: 日本語へんでした。
    フォーラム: インストール
    返信が含まれるトピック: PHP5.4のphp-gdを削除する方法を教えてください

    機能していなければライブラリディレクトリから直接モジュールを削除すればよいと思います。
    でもインストールはなされていないようなのですが機能はされていたのでしょうか。
    コンパイル済をコピーして直接パスをかけば動くような気もしますが動いていなければほおっておいてもいいのではないかと思います。

    php7のものも依存関係が正しく設定してあれば混在していても問題ないかと思いますがソースからコンパイルしてインストールするにあたりt1libなどライブラリは足りていたでしょうか。

    私もあまりくわしくなく、ワードプレスとの関連性は比較的薄いかと思われますのでご質問にあたり別途手段をご検討されてみてはいかがでしょうか。

    フォーラム: 使い方全般
    返信が含まれるトピック: index.htmlで編集したい

    そうなのですね。
    ホームページ、ブログの作成にあたって index.html などHTMLソースデータを編集する必要がない前提なのがCMSの特徴ですので、他プロバイダ提供のブログサービスと同じように使い始められるのがよいのではないでしょうか。
    他の方は激しくカスタマイズされたりプラグインを導入されたりしていますが、基本的にはホームページ作成の負担軽減のためにあります。
    ここでまた「サイトの構築」という目的を完遂するための道具を「カスタマイズの労力をふるう」と制作作業へ原点回帰する必要はないと思います。
    ご利用のプランでご利用可能なプラグイン、テーマをお試しになったり記事の掲載について、さらに新しく取り組まれる際にまた挑戦されてみてはいかがでしょうか。

    ワードプレスは記事の中にHTMLタグ、デザイン構成を埋め込むことができます。記事入力の画面でエディタをテキストに設定してお試しください。
    ページのデータをカスタマイズする前にたくさん試せることがあると思います。

    フォーラム: 使い方全般
    返信が含まれるトピック: index.htmlで編集したい

    index.html はURLとしてどういった表示でされているものでしょうか。

    ・http://ドメイン名/
    ・http://ドメイン名/index.html
    ・http://ドメイン名/******/
    ・http://ドメイン名/******/index.html

    また編集なされた画面の内容は、ワードプレスで作成した記事が反映されているものではないのでしょうか。
    (固定ページまたは投稿にて作成したデータが index.html で表示されているのでしょうか)

    いずれにしましてもブラウザでデータの変更が可能なのでサーバーの情報も変更、とは必ずしも同一資源として実態がありそれを可能というわけではありません。

    ワードプレスはCMSという機能で、バラバラにしたページデータをHTMLに置き換え組み合わせて発信し、受け取り側はブラウザでそれを組み合わせ表示させます。
    その受け取ったデータを、受け取り手が一部変更をして表示させたり、中身を確認したりすることはブラウザよって可能である場合があります。
    こちらで可能なのは、最終的なデータの構成を微調整したり要素を確認したりすることができるにとどまり、サーバーのデータについては
    「そのデータをつかさどる部分の出力についてサーバー側の部品を変更をすると、最終的にブラウザに表示されるようになる」ということを知るのみにとどまります。

    例えでお話しますとサーバーが農場でそこでの生産物をご自宅で調理ができるセットにするのがCMS、そのメニューの材料セットがインターネット経由でブラウザに配送され、ブラウザが調理して表示されます。
    なので調理の段階で味付けをかえたからといって農場の収穫物が変わるわけではないのです。
    末端部分で変更が可能な理由としては、「毎回同じ味付けをして好みであるので、出荷段階でその味に調整してくれないか」という意見が出せるというところにとどまります。

    index.html の表示状態について、もう少し情報をいただけませんでしょうか。

    さらっとなのですがGitにて当該プラグインを拝見いたしましたところ特に問題になる箇所が見受けられなかったのですが、もしかするとメディアのURLが http となっている箇所はございませんでしょうか。
    メディアと記事を結びつけるプラグインだということですと、そこで生成された記事が http である場合そのページをSSLに転送を繰り返しているのはどうでしょうか。
    たとえば wp_posts における image/jpeg 等の GUID 項目について http で記載されているなどとの関係はいかがでしょうか。
    この点につきましては初見で取り組みますと 画像の指定方法 記事への記載方法 プラグインでの結びつけ方法 プラグインの根本的な動作 など複合的になってくると思いますので、プラグイン作者様とご連絡が取れると最も良いかと思います。
    ご確認くださいませ。

    .htaccess の設定に問題はないと思うのですが、ワードプレスの設定がページのアドレスをhttp://のままにされている箇所がございませんでしょうか。
    たとえば wp-admin/options-general.php におけるサイトの情報などはいかがでしょうか。
    正しい動作で301転送をかけた先からURLがデータベースのものへ転送され、また301となっているのではないでしょうか。
    一旦SSLの設定を休止してご確認いただけると幸いです。

    ワードプレスと直接関係のないところと、良い書き方かどうか微妙なところですが構文について進言いたします。

    if文は便利さに対して単純性が求められる部分で、ここにひとまとめに判断基準をつめこむと動作の確実さがさがりメンテナンス性がさがります。

    いちばん面倒ですがいちばん管理がしやすく確認もしやすい書き方を書いてみます。

    $check = 0;
    if($postlink){ $check+=1; }//A
    if(in_category('process')){ $check+=2; }//B
    if(post_is_in_descendant_category( get_term_by( 'slug', 'process', 'category' )){ $check+=4; }//C
    //以降のフラグは 8 16 32 64 となります。
    switch($check){
    case 0:
    //どれも合致しない
    break;
    case 1:
    //Aのみ合致
    break;
    case 2:
    //Bのみ合致
    break;
    case 3:
    //ABみ合致
    break;
    case 4:
    //Cみ合致
    break;
    case 5:
    //AC合致
    break;
    case 6:
    //BC合致
    break;
    case 7:
    //全合致
    break;
    }
    

    これで確実な動作が得られると思います。メンテナンスも条件を増減するに追加と削除で、前の数値の二倍を設定するだけでいくつでも全分岐の候補あげることができます。
    ANDとORが混在している状態は、今回の動作に問題がなければよいのですが、あまりよいと感じることができませんでしたのでここはスマートでない気がします。
    そんなに重要ではないところですが、なにかのご参考になれましたら幸いです。

15件の返信を表示中 - 46 - 60件目 (全226件中)