msio

projectという単位での読み込みに対して記事のパラメータ以降を与えることで表示のようなので
projectの引数による記事読み出しについてページがなくともprojectが存在しているので
記事のないprojectが返っている結果indexの読み出し止まりになっているのではないでしょうか。
記事がない場合や記事の記載の法則性に則っていない場合は
projectが404を読み出すように設定するか
対象がない場合はproject自体がemptyを返すように設計をする必要があるのではないでしょうか。
この状態をそのまま４０４判別に基本機能だけで調整するのはむつかしいことかと思うのですが
なにかよい方法がありそうな気もするのでなにか思いついたら追って申し上げます。

すいませんワードプレスともPHPとも関係がないお話かと思いますので終わってしまうかもしれないので提案を書いておきます。

<?php
//現状
//それぞれの倍数ごとに唐突にふりわけられ公倍数は分岐上位に含まれます
//カウンタ初期化
$loopcounter=0;
//これは記事ループの代用です
for($i=0;$i<256;$i++){
	$loopcounter++;
	if ($loopcounter <=1 || $loopcounter%12 == 0){
		echo "A".$loopcounter."<br />\n";
	}else
	if ($loopcounter%8 == 0 || $loopcounter%9 == 0){
		echo "B".$loopcounter."<br />\n";
	}else{
		echo "C".$loopcounter."<br />\n";
	}
}
?>
<?php
//カウンタ初期化
$loopcounter=0;
//これは記事ループの代用です
for($i=0;$i<256;$i++){
	//これはループ記述ではないですが変数の位置が初期化されもどるので
	//実質ループになっています
	//小ループ先頭の場合
	if($loopcounter==0){
		echo "A".$loopcounter."<br />\n";
	}else
	if($loopcounter > 0 && $loopcounter <=6){
		//小ループ1から6の場合
		echo "C".$loopcounter."<br />\n";
	}else
	if($loopcounter >= 7 && $loopcounter <=8){
		//小ループ7から8の場合
		echo "B".$loopcounter."<br />\n";
	}else
	if($loopcounter >= 9 && $loopcounter <=10){
		//小ループ9から10の場合
		echo "C".$loopcounter."<br />\n";
	}
	//小ループを担う部分
	if($loopcounter <10){
		//10以下であれば進める
		$loopcounter++;
	}else{
		//10に至ればループバック
		$loopcounter=0;
	}
}
?>

• この返信は7年前にmsioが編集しました。理由: 解決すれば幸いです。

ご質問されている意図を明確に把握できかねている気がするのですが
・小説を作成したい
・その小説をホームページに掲載したい
・そのホームページを作成したい
・作成をご自身からだれかに依頼したい
ということなのでしょうか。
・小説を掲載する無料のホームページにwordpress.comを利用したい
とはまた異なるお話でしょうか。

もう少し必要な事柄について、身近な方と具体的に必要な情報を検討されてから
もしワードプレスを選択される場合は、ご質問されてはいかがでしょうか。

現在は必要だと思われる情報に対して相対的な意志関係しか把握できていないと思いますので
これを検討するにはだいぶ多くの時間と要素を話し合う必要があるのではないかと思います。
絵にしてみましたが、明るくない部分を前段階として決定されて後か、もしくはもう決まっていらしたらお話できる範囲でご提示いただけると回答がなされやすくなるかと思います。

当該クラス内のAタグを全部非表示にするようにしてswiper-slide-activeのクラスに表示させるようスタイルを記述するのはどうですか？

.htaccess は上のものが下にも適用されるのでより上にあれば動作をすると思います。
ただディレクトリがみえてファイルも見えては問題なのでおきまりの設定はつけておいたほうがいいかと思います。
あと正規表現の抽出もそうですがアスタリスクでワイルドカードで抽出条件にした部分は
$1などで取り出せて、前から順に$2、$3といったかたちで取り出せます。
以下のような形でお試しされてみてはと思います。

#フォルダの一覧を表示しない
Options -Indexes
#特定の拡張子（ドット以下の文字）のファイルはアクセスさせない
<Files ~ "\.(htpass|htaccess|txt)$">
    deny from all
</Files>
<IfModule mod_rewrite.c>
#書き換えを可にする
RewriteEngine On
#書き換え条件として状態が旧ドメインである場合
RewriteCond %{HTTPS_HOST} ^good-show.net
#条件適の場合条件以下を前提+条件にて恒久的に転送して完了
RewriteRule ^(.*) https://detokkus.endevperu.org/$1 [R=301,L]
</IfModule>

以前に喩えました私の話がよろしくなかったようでよい進言になっていなかったのだと反省しております。
フィルターフックについて、こりずに再度たとえてお話をしてみます。

読み込み開始から描画までの間サーバーでこなす仕事がベルトコンベアー上に並んであり
ライン製造のように動作をしていくのですが
いくつかチェックポイントがあり、係員が作業していて
その係員の名前が　フックなのです。

その係員フックに　フィルター動作について指示を出すのがフィルターフックです。

たとえば、ライン製造工程の「アーカイブのリンクを取得する」という段階に立っているフックに対して
「あなたのフィルター作業は、このタイミングの場合具体的にこうしなさい、抽出の方法をこうしなさい」
と、命令するのがフィルターフックなのです。

そのライン製造のタイミングには、ほかの通常動作でフィルター処理をするとき用に現場内で準備されたデータがまわりにある状態です。
アーカイブがあり、リンクがあり、抽出要項があり、それらで動作する準備があり
それらをつかって抽出する際、具体的な指示をだすのが、フィルターフックです。

なので、その段階で生成されている変数や関数をパラメータとしてなんの脈絡もないように見える形で
とりこむことも可能です。
その読み込む時点では生成されていて、作業が通過すると破棄される一時的な変数もあります。

これは、個人で作成された独自関数のようにパラメータや、元データをつくったり準備したりする必要の有無がことなります。
個人で関数をつくった場合、前後になにも脈絡がないのでゼロからデータを準備しなくてはなりません。

ですがフィルター動作内ではフィルター動作のために準備されたデータがその時点にはあります。
アーカイブ処理をするというラインにはアーカイブデータがあり、それを横取りするというか
その処理の途中に命令を挟むというか、その時点でのそのデータに命令をだすのがフックです。

なので、ラインをはずれて脈絡なく関数を読み出しても、なにも準備がなされていないので値がないといわれます。

フックをするとアーカイブのリンクを生成する段階において、アーカイブのリンクデータ抽出方法について具体的な変更要領を含むと
ワードプレスの恒常動作であるアーカイブリンク抽出動作が、なにかひと手間加わったように出てくることになります。

どうでしょうか。これでウィジットにつかうものではないようなイメージはつきますでしょうか。

どうも当該のプラグインは特定のページにだけSSLを設定するというニーズについてのみに人気がありそれ以上の必要性がなく更新されていないにかかわらず利用がされているようです。
いつ現行のバージョンと合わなくなるかはわかりませんが、おそらく改造したりするなどで対応できる人は使いつづけそうかとも思います。
とても単純な作業なのでだれでもこの機能を主としたプラグインをつくることはできると思いますが、簡潔に各設定の機能や画面を整備している細やかさについてはこれに勝るものを作るのはただただ面倒なので対抗候補がないような気がします。
これは自己責任でつかわれている方が多いのではないかと思いますので、使いたい旨についてあえて有限的である可能性を説明したうえで各個人に利用を判断してもらったらと思います。

プラグインをつかわない他の方法としては
１全部SSL化する
２お問合せページを静的に作成しSSLをつける
３特定のアドレスのみ効果を示す独自のプラグインを作成する

などあるかと思いますが
「お問合せフォームはワードプレスのプラグインで作成するので静的ページ作成は無理」やプログラミングをそこまでしないなどあるかと思います。
全部のページをSSL化してもよいのではと思うのですが、全体をSSL化しないのはなぜでしょうか。
外部参照が多く混在でエラー表示が気になるなどあるのでしょうか。

ほかに静的ページで動的なワードプレスのお問合せフォーム整形データを読み込んで通常のページをSSL化したように表示することもできるかと思います。
ですが一旦作成したページを自身で読み直してリバースプロキシ的な動作はいろいろと問題もあると思います。
無駄な負荷が余計にかかるのと動作検証が面倒なので、いずれしにしても「古いプラグインでも動けばそれでいい」が勝る気がします。

これについてばかりは、全体をSSL化しないのであれば、古いプラグインについて自己判断でとしか言えない気がします。

ただ、サイトを数多く作成され利用される方はプラグインでお問合せページを作成せずテーマや静的ページで作っていることもあるので、特定のSSLという形などはとりやすい場合があると思います。
お問合せフォームは固定的な条件動作の繰り返しが多いので「お問合せフォームセット」のようなものを自前で準備しているところもあります。

個人的には全部をSSL化することをお勧めしますがいかがでしょうか。