Bitrixモジュールの開発と販売の瞬間

ここでは、Bitrix拡張の技術的側面（ユーザーが気に入らない理由の1つ）だけでなく、Bitrixエコシステムに関連する瞬間（気に入らない別の理由）についても説明します。ドキュメントを繰り返さないでください。

この記事では、cmsや会社の主観的な評価はなく、モジュールで稼ぐのに役立つ乾燥した事実と思考のみがあります。 Marketplaceを通じてモジュールを販売した私たち自身の経験が教えてくれたポイントをリストします。 それらのいくつかは非常に明白で一般的であるように見えますが、逆に、プラットフォームに非常に固有のものもありますが、それらはすべてBitrixモジュールでの作業に関連しているため、リストに含まれています。

この記事は、マーケットプレイスでモジュールの販売を開始したい、または彼の助けを借りて会社を宣伝したい人に役立ちます。

購入ではなくサポートで獲得

もちろん、購入は支払われる可能性があります。理想的な世界では、100である必要がありますか？ 既製のソリューション（既製のソリューション）から得られる収益額。ただし、購入者はほとんどの場合プログラマーではなく、プログラマーはスタッフにいません。 これがcmsが作成するエコシステム、特にBitrixです。

したがって、デザインの機能または編集を統合するタスクは、多くの場合、作成者自身にあります。 また、プログラマーの時間は高価なので、購入に加えてクライアントからお金を取り、クライアントに2回支払う必要があります。

良い解決策は、販売から稼ぎたいという事実にもかかわらず、モジュールの価格をゼロまで引き下げることですが、労働時間の価格を明確に宣言することです。 インストールの自律性が高まると、購入価格を上げることができます。 ただし、Bitrixガイドに従ってサイトが作成されるとは限らないため、自律性が100％になることはありません。

もちろん、アドバイスは、モジュールでお金を稼ぐつもりである場合にのみ関連します。

モジュールを再インストールできるようにしましょう

モジュールを削除して再インストールするだけでよい場合もあります。 モジュールが完全にダウンロードされなかった、何らかの形で更新が曲がった、誰かが購入者のウェブサイトでソリューションのソースコードを変更したなど、何かがうまくいかなかった場合、100万の状況があります

問題は、モジュールがデータベースまたはファイルにデータを保存する必要があることです。

もちろん、モジュールが完全に取り外された場合、その存在の痕跡をすべて置き換えることは価値があります。そうでなければ、いずれにしても節度に合格することはできません。 しかし、逆に並べ替えるときは、ユーザーがすべてを再入力して構成する必要がないように、何らかの方法ですべてを保存する必要があります。

Bitrixは通常、アンインストール中のモジュールトレースの完全な消去について述べているという事実にもかかわらず、モジュールを削除するときにデータを消去するかどうかを選択することが、この状況での最善の方法です。

1つのモジュール内の多くの機能、または多くの小さなモジュール？

コメントモジュールの例を使用して問題を説明します。

そのため、このような製品（コメントモジュール）を作成し、Marketplaceでリリースしました。 製品に関するコメントを書くために使用します。 また、他のユーザーを削除、編集、返信することもできます。

しかし、あるバイヤーは、あなたが持っているもの、そして同じデザインであっても、評価、写真、長所と短所の完全なレビューであることを望んでいました。

2番目のモジュールを実行するか、最初のモジュールの機能を拡張しますか？ 質問は純粋に個人的なもののように思えるかもしれませんが、Bitrixエコシステム全体を見ると、すぐに使える多くの機能を備えた高価なcms、典型的なサイト、さらにはデザインサイトでさえストアで非常に人気があり、開発価格が非常に高いため、冗長性と価格の傾向を特定できますバイヤーにとってそれほど重要ではありません。

また、買い手はしばしばビジネスであるため、販売には非常に長い時間がかかり、価格は物理的に作業するときほど重要ではないことも考慮する価値があります。 人。

さらに、私たちは顧客と直接話をしましたが、彼らの多くは、どの特定のチップのために高価な製品を買ったと答えました。 たとえば、バナーが好きだったため、数万ルーブル（ひどいレビュー付き）のWebサイトデザイナーを購入しました。 はい。おそらく、顧客からBitrixが必要な理由を聞いたことがあるでしょう。同じ答えを聞いたことがあるでしょう。

カスタマーサポート

だから、きれいで読みやすいコード、書かれたドキュメント、指示を備えた優れたモジュールをリリースしました。モジュールは特定の明示的な機能のみを実行し、インストールされます-ダウンロードして使用します。 しかし、実際には、少なくとも何らかの形でモジュールが関係しているサイトに問題がある場合、最初にあなたにメッセージを送ります。

ちなみに、モジュールのインストール後、別のモジュールまたは主要な設計変更をインストールする前に購入者のWebサイトで発生した問題も、モジュールの問題と見なされます。 コールバックモジュールがあり、それが4か月前に設定されていて、1Cでのアンロードが昨日落ちたとしても、彼らはあなたに書き込むことができます。

これは、一部はBitrixの技術サポートポリシーによるものです。 彼らは全員に答えますが、誰かのコードを見るとすぐに手を洗います。 たとえば、モジュールが何らかのカーネルイベントを使用している場合（そして、おそらくそれを使用している場合）、それらは使用されます。 このシナリオがエラーシナリオのどこかで呼び出された場合、サポートはクライアントの問題を迅速に転送します。 たとえば、注文の作成時にエラーが発生し、モジュールには商品の価格を受け取るためのイベントハンドラーがあります。 そして、彼らは理解することができます。 他の人のコードを無料で理解したい人はいますか？

そして、指示を読んだり、直感的な設定ページにアクセスしたりする人はほとんどいません。80％の場合、すぐにテクニカルサポートに連絡します。 おそらく、あらゆる活動分野で。 しかし、巨大なBitrix管理者パネルとそれを使用するためにいくつかのコースを読む必要性は、火に燃料を加えているようです。

価格設定と労働計画を立てる際には、これを考慮してください。

コンポーネント接続設定を介したカスタマイズに対するコピーを介してコンポーネントテンプレートをカスタマイズする機能

すべてのサイトは異なっているため、たとえば、ラベル、デザイン、要素セットなどの他のテキストなど、コンポーネントとは異なるものが必要です。

Bitrixでは、コンポーネントテンプレートをコピーして、独自の方法で変更できます。 これは通常の方法です。 しかし、経験から、このようなアクションからユーザーを保護する方が良いことが示されています。

結局のところ、テンプレートにエラーがある場合、または単に改善する場合は、新しいチップを追加してください。カスタマイズされているため、クライアントからテンプレートを更新することはできません。 そのため、クライアントが自分の機能を表示する際のミスを手伝うことすらできません。

そのため、コンポーネントを接続するためのできるだけ多くの設定を提供して、コードを編集せずに、単に設定を「ねじる」だけで必要なすべてのカスタマイズを実行できるようにすることは良い解決策になります。

このアプローチの追加の利点は、プログラマーにクライアントが必要ないことです。

JavaScriptコードの保存

技術的なポイント。カスタマイズにも関連しています。 一般的な形式のコンポーネントの構造は次のとおりです。

• my.component /
  
  • class.php
  • component.php
  • .parameters.php
  • .description.php
  • テンプレート/
    
    • .default /
      
      • .parameters.php
      • result_modifier.php
      • template.php
      • style.css
      • script.js
      • component_epilog.php
      • lang /
        
        • RU /
          
          • .parameters.php
          • result_modifier.php
          • template.php
          • component_epilog.php
          
          
        
        
    
    
  • lang /
    
    • RU /
      
      • class.php
      • component.php
      • .parameters.php
      • .description.php
    
    

そして、js内にajax呼び出しまたはロジックがある場合、それをやり直す最良の方法は次のとおりです。

• my.component /
  
  • class.php
  • component.php
  • script.js
  • .parameters.php
  • .description.php
  • テンプレート/
    
    • .default /
      
      • .parameters.php
      • result_modifier.php
      • template.php
      • style.css
      • script.js
      • component_epilog.php
      • lang /
        
        • RU /
          
          • .parameters.php
          • result_modifier.php
          • template.php
          • component_epilog.php
          
          
    
    
  • lang /
    
    • RU /
      
      • class.php
      • component.php
      • .parameters.php
      • .description.php
      
      

つまり、重要なjsをコンポーネントに配置し、テンプレートに保持しません。 後者では、APIのみが、要素にハングアップしたハンドラーを使用します。

まあ、ありがとう、KO。 共通のjsモジュールは、モジュールフォルダー自体に移動できます。

これの意味は、コンポーネントテンプレートフォルダー内にあるすべてのものは、ロジックではなくディスプレイのみを参照するということです。 したがって、テンプレートをカスタマイズすると、script.jsを含むフォルダー全体がコピーされます。 また、サポートと更新に関する問題は前の段落と同じですが、提案されている構造では、それらを大幅に減らすことができます。

JQueryおよびBitrix JavaScriptライブラリ

純粋なjsでajax呼び出しを記述したり、ホバー処理を実行したりする人はほとんどいないため、多くの人がjQueryに惹かれていますが、jQueryはランダムなサイトで見つけることは困難です。 また、一部の人々は、Bitrix jsライブラリについて知っています。これは、使いやすいように何らかの種類のラッパーも提供します。

しかし、実際には、cms jsライブラリ自体は本当に無意味であり、たとえば、何らかの理由でコンポジットと連携しないため、時には有害でもあります。

そしてjQueryの問題は、ほぼどこでも接続されていることですが、それでもどこでも接続されていないことです。 また、接続されている場合は、バージョンが古すぎる可能性があります。

バニラで記述するか、「Do jQuery connect？」コンポーネントを設定することをお勧めします。これにより、この瞬間を細かく制御し、必要に応じて無効にすることができます。 ちなみに後者は、モジュール開発者の間でかなり一般的な方法です。

可能な限り一意のcssクラス、可能な限り多くのセレクターのルール

もちろん、クラス名は一意である必要があります。これは、サイトがあなたと同じクラスを使用できるため、視覚的な部分を持つWeb上のすべての標準ソリューションに適用されます。 通常、クラスの名前にモジュールの完全な名前を含め、BEMの名前を使用します。

しかし、「サイトビルダー」の存在（および人気）により、各セレクターのほぼすべてのパラメーターを明示的に記述せず、使用しない場合は疑似要素の「content： ''」を記述します。 さらに、CSSでの「！重要」の多数の使用に備えてください。

コードを編集する必要がある場合は、常にftpアクセスを使用してください

Bitrix管理パネルには、ファイルエディターが組み込まれているため、ブラウザーでコードを編集できることをご存知かもしれません。 しかし、経験により、問題を修正または分析するためにサイト上の少なくともいくつかのファイルを編集する必要がある場合、init.phpで呼び出されるいくつかのコード（およびこれは多くの場合）とすぐにサイトに触れることができるため、すぐにftpを取ることをお勧めします管理パネルから変更をロールバックする機能がないとクラッシュしますが、これも機能しません。

さらに、一部の開発者は、Bitrixでコードを見た場合にページがクラッシュするように管理しています。 この動作の理由はまだ明らかではありませんが、そのような場合は発生します。

したがって、ブラウザを使用してファイルを編集することは、サイトを1分以内にリレイズできない場合、かなり危険なタスクです。

バイヤーはほとんど常にビジネスです

モジュールが販売されている間ずっと、IPまたはLLCがなかったため、決済アカウントを持っていないバイヤーと一度だけ話しました。 もちろん、バイヤーの中には複数の個人がいることは確かですが、すべてのバイヤーが私たちに書いているわけではなく、一部はただマーケットプレイスで黙って購入しているため、見つけるのは困難です。

少なくとも安価ではないため、Bitrixでの公式ビジネスの優位性は顧客のほぼすべてのセクションにあるように思われます。

私たちにとって、これは売り手として、商品単位あたりの大量の売上高を意味しますが、顧客会計士との購入と苦痛のサイクルが長くなります。

悪い環境

モジュールは、Bitrixカーネルのコード、サイト自体のコード、およびクライアントが購入した他のモジュールのコードの影響を受けます。

何を言っても、カーネルコードを心配する必要はありません。 何万回もテストされており、サイトごとに変更されることはなく、更新には常に下位互換性があります。 はい。テクニカルサポートが無料でお手伝いします。

しかし、サイト自体のコードは別の問題です。 これはひどいコードになる可能性があります。多くのサイトは長い間作成されていたため、PHPに入るためのしきい値自体が非常に低いため、多くは悪いプログラマーによって作成されました。

反対に、一部のサイトは「優秀な」プログラマーによって作成されましたが、フレームワークまたは他のシステム（自己記述型）から来ており、Bitrixを理解しようとさえしませんでした。 どうやらプライドのため。 ちなみに、Bitrixから名前と管理者のみが残り、Bitrixモジュール、およびそれに応じてイベントとデータベーステーブルをバイパスして、ほとんどの機能が実行される場合、コードの別の「終了」があります。

さらに、他の開発者のモジュールは、モジュールをハンドラーとオーバーラップできます。

これにはすべて、主にサポートに問題があります。 また、モジュールが単にクライアントのサイトにインストールされていない、完全にインストールされていない、または動作しない可能性があることに注意してください。サイトを長時間デバッグし、クライアントに余分に支払う必要があることを説明する必要があります それ以外の場合は何も動作しないため、サイトで動作します。

D7をよく知る必要がありますか？

かなり前に、Bitrixはシステムの新しいコアをリリースしました。ほとんどすべてが書き換えられ、多くの新しいチップが登場し、クラスが少し統一され、すべてがOOPになりました。 しかし、私たちは純粋なd7にソリューションを記述しないことに決めました。

これは、テクノロジーの急増のためです。 リリースはかなり前に行われたという事実にもかかわらず、ときどき、古いコアにサイトがあります。 そのようなクライアントはほとんどなく、それらに多くの問題が発生する可能性が高くなります（更新され、すべてが飛行するため）。したがって、それらは考えを無視することができます。

私たちにとって重要な要因は、ドキュメントの欠如と、テクノロジが少し「実行」されたという事実でした。つまり、インターネットで解決策をすばやく検索しても問題の解決策が得られない可能性があります。

しかし、古いカーネルのサポートにより、単一の問題はまだ発生していません。

結論の代わりに

もちろん、いくつかのポイントは「モジュールを書くには、あなたはそれらを書かなければなりません」のように聞こえます。 しかし、経験に満ちた間違いを避け、自分で入力しないように、これらすべての点を認識し、念頭に置いておく方が良いでしょう。

社内でチートシートとして使用するために、経験を積んだときに記事を補充します。

また、モジュールの開発に関するBitrix公式ドキュメントへのリンク。