मैं रूबी सीएमएस (या प्लगइन) की तलाश में हूं जो एक गिट रिपोजिटरी में स्थित सामग्री को सेवा और संपादित कर सकता है। मैं अपनी सामग्री को डीबी में रखने में बीमार हूं। उपयोगकर्ता, सेटिंग्स, टिप्पणियां, ठीक है। लेकिन कोई और सामग्री नहीं।गिट-आधारित सामग्री प्रबंधन?
किसी पृष्ठ पर प्रत्येक लाइव संपादन को स्वचालित रूप से सर्वर-साइड विलय की आवश्यकता को रोकने के लिए स्वचालित रूप से प्रतिबद्ध होने की आवश्यकता होगी। साथ ही, जब भी नए बदलाव धकेल जाते हैं, उन्हें फाइल सिस्टम पर तुरंत अपडेट करने की आवश्यकता होगी।
रिफाइनरी सीएमएस दस्तावेज कुछ ऐसा ही प्रतीत होता है, हालांकि शायद रिमोट रिपोजिटरी के साथ।
मैंने गिटमोडेल और गिट-ब्लॉग के बारे में पढ़ा है, लेकिन मैं अभी भी कुछ ऐसी चीज ढूंढ रहा हूं जो मेरी आवश्यकताओं से मेल खाती है। [संपादित करें: GitModel हाथ से संपादित करने के लिए जब सबसे CMSes के साथ प्रयोग किया बहुत कठिन है, और Git ब्लॉग स्थिर फ़ाइल पीढ़ी का उपयोग करता है।]
संपादित करें: सामग्री के लिए डेटाबेस के विरुद्ध मेरे पूर्वाग्रह केवल उन साइटों के एक उच्च डिग्री की जरूरत है कि पर लागू होता है अनुकूलन, और किसी भी सीएमएस का उपयोग नहीं कर सकते हैं। साइटें जिनके कोड इसकी सामग्री के रूप में विकसित होते हैं। यह तब होता है जब डीबी में सामग्री होना एक सपना दुःस्वप्न है। जब आपको एक ही समय में सामग्री और कोड को फोर्क करने की आवश्यकता होती है, तो वे उन्हें बाद में उत्पादन में विलय करते हैं। डीबी शाखा नहीं है और विलय नहीं करते हैं।
मेरे पास ऐसी साइट है।
डीबी-केवल सामग्री के पक्ष में प्रदर्शन तर्क शून्य और शून्य है। मैंने 5 साल पहले एक सीएमएस लिखा था जो फाइल सिस्टम से डेटाबेस को सिंक्रनाइज़ करता है, जहां फाइल सिस्टम हमेशा मास्टर कॉपी होता है। यह 10,000 प्रतिक्रिया समय और 2 एस reindex समय बनाए रखने, आसानी से 100,000 पृष्ठों के लिए स्केल किया गया। सभी सामग्री, मेटाडेटा, टैग, तिथियां इत्यादि की पूरी तरह से खोजने योग्य इंडेक्स और हेक, मैंने इसे ग्रह, एएसपी.नेट पर सबसे धीमे, सबसे दर्दनाक रूपरेखा में लिखा है। यह वास्तव में लगभग एएसपी.NET सहनशील बना दिया है, और इसने विभिन्न कंपनियों को बहुत अच्छी तरह से सेवा दी है, क्योंकि उनके ऊपर उल्लिखित एक ही तरह की साइट थी।
छोटे साइटों बस एक में कैश मेमोरी का उपयोग कर सकते हैं, पूरी तरह
db-केवल सामग्री के लिए एक वैध तर्क संपादन के scalability है db सामग्री लंघन। संपादकों को सभी एक ही सर्वर का उपयोग करना चाहिए, हालांकि परिवर्तनों को बाहर की तरफ दोहराया जा सकता है। लेकिन त्वरित-बदलते, अत्यधिक अनुकूलित साइट्स के मामले में जो सामग्री को अक्सर सामग्री के रूप में बदलते हैं, कहा गया कोड और सामग्री का वितरित/सामुदायिक संपादन असंभव है। समुदाय/वितरित संपादन एक अलग सिस्टम का उपयोग कर सकते हैं।
अब तक, निकटतम मैं क्लाउड 9 का उपयोग सामग्री (गीस्टा सीएमएस) के गिट रिपोजिटरी को संपादित करने के लिए कर रहा हूं, फिर कमांड लाइन के माध्यम से परिवर्तनों को दबाएं। यह धीमा है, लेकिन कम से कम यह वेब-आधारित है यदि मेरी देव मशीन आसान नहीं है जो मुझे पता चलता है कि मैंने एक लेख में अपना नाम गलत लिखा है। अभी भी बेहतर विकल्पों की तलाश में है।
क्या आप इस बारे में कुछ बात करना चाहेंगे कि आप डेटाबेस में सामग्री क्यों नहीं चाहते हैं? –
"मैंने गिटमोडेल और गिट-ब्लॉग के बारे में पढ़ा है, लेकिन मैं अभी भी कुछ ऐसी चीज ढूंढ रहा हूं जो मेरी ज़रूरतों को थोड़ा करीब से मेल खाता हो।" उन चीजों के बारे में क्या है जो आपको असंतोषजनक लगता है? – MatrixFrog
गिटमोडेल फाइलों को कैसे लिखा जाता है, इस पर बहुत लचीलापन प्रदान नहीं करता है, और उन्हें सीधे संपादित करना मुश्किल बनाता है। गिट-ब्लॉग स्थिर पीढ़ी का उपयोग करता है, जबकि मेरी अधिकांश साइट में उन्नत गतिशील कार्यक्षमता होगी। –