שיחה ההאקר Emad
11 באוגוסט 2012 – 21:50 | 31 תגובות

קבוצת ההאקרים הפועלת תחת שמו של אימעד מורניה, RememberEmad, ופרסמה כי פרצה לשרתי חברת ההוסטינג WebGate, פרסמה היום קובץ נוסף ובו כ-500 פרטים נוספים ובהם שמות משתמש וסיסמאות של אתרים שאוחסנו ב-WebGate. נראה כי העימות בן קבוצת …

המשך קריאה »
geek

חנון זה מגניב. תרבות החיים האינטרנטית-טכנולוגית-גאדג'טית. הדברים שמבדילים את הנערים מהגברים.

הרשת

סיפורים מהרשת, בעיקר זו הישראלית. מה קורה, מי קורה ולמה קורה.

וורדפרס

בעיקר תבניות מתורגמות לעברית ולפעמים דברים שקשורים לבלוגים ובלוגרים.

מערכות ניהול תוכן

על מערכות ניהול תוכן באינטרנט, בעיקר חינמיות ובעיקר בעברית. כלים לבניית אתרים, פורומים, גלריות ועוד.

פלטפורמות חברתיות

על רשתות חברתיות, כלים לבניית רשתות ופלטפורמות חברתיות וכל מה מכונה web 2.0

ראשי » הסיפור המרכזי, מדריכים, מערכות ניהול תוכן

בניית מערכת ניהול תוכן מההתחלה

מאת ארז וולף בתאריך 25 ביוני 2008 – 7:2322 תגובות

פוסט אורח מאת טל ברזינצקי

"האם יש טעם בבניית מערכת לניהול תוכן מהיסוד ?"

זוהי שאלה שתמיד מטרידה אותי לפני הקמת אתר חדש. הרשת מלאה בכלים חינמיים ומקצועיים לניהול תוכן, כגון WordPress ו-Drupal, בעלי קהילה גדולה של מפתחים ועידכונים שוטפים. מערכות אלו גם מאפשרות להרחיב את הפונקציונליות ולהתאימן לצרכים של אתרכם. במידה ולאתר שלכם אין צורך בתפקוד מאוד לא סטנדרטי, רבים הסיכוים שתוכלו למצוא מערכת בנויה ובדוקה שתוכלו לבסס את האתר עליה.

מדוע לשקול כתיבת מערכת חדשה ? הסיבה הראשונה היא שבתור מתכנת אני "פריק שליטה" כשזה נוגע להבנה מלאה של המערכת בה אני משתמש. אני אוהב לדעת מה כל קטע קוד עושה וכיצד הוא עושה זאת. בחירה במערכת מוכנה תמנע ממני את היכולת להרחיבה בקלות ולהתאימה לצרכים שלי.

סקירה קצרה של מספר מערכות מוכנות ברשת, מגלה כי רובן נכתבו בשפת php או ASP.NET ומשתמשות בבסיס נתונים mySQL. אם ברשותכם חבילת איחסון, היא עלולה שלא לתמוך בטכנולוגיות אלו. חיפוש אחר מערכות הכתובות בשפת ASP או כאלו המאפשרות להשתמש בבסיס נתונים של אקסס, טכנולוגיות יעילות פחות אך נפוצות, מובילה למבוי סתום.

הסיבה האמיתית שמושכת אותי לכיוון מערכת חדשה מהיסוד היא שאתרים רבים ברשת פשוט דומים מדי אחד לשני. יש להם לוגו שונה, צבעים אחרים ותמונות מקוריות, אך משהו מרגיש כי כבר ראינו את האתר הזה בעבר. היחודיות של האתרים נפגעת מהעובדה שרובן משתמשות ב-CMS מוכן. אתרי WordPress אומנם ניתנים לעיצוב מחדש, אך מכיוון שהם מוכוונים למטרה אחת, בסופו של דבר התוצאה מאוד דומה. אם אתם רוצים יחודיות, אתם רוצים מערכת חדשה.

תבניות ועיצובים של וורדפרס

בניית מערכת בשבעה ימים

אם החלטתם להצטרף להרפתקאה ולכתוב מערכת לניהול תוכן משלכם, בוודאי תרצו לשמוע כיצד ניתן להקים את הבסיס למערכת כזאת. הניסיון שלי הראה כי תוך שבעה ימים ניתן לכתוב מערכת ניהול תוכן מינימלית שעובדת. את המשך הפיתוח ניתן לעשות עם הזמן, כשהצורך עולה.

היום הראשון – תכנון המערכת

זהו כנראה השלב החשוב ביותר בבניה. בשלב זה מומלץ לבקר באתרים רבים של מערכות CMS ולקבל רעיונות עבור המערכת שלכם. שימו לב לפיצ'רים שאתם אוהבים במערכת ובמיוחד לאלו שאתם לא.

מומלץ להתחיל בציור סכמתי של הדפים שמתוכננים להיות באתר. אם מדובר בבלוג, אפשר להתחיל לצייר סכמות לעמודי הפוסטים, עמודי התגיות ולעמוד הראשי. בנוסף יש לצייר את איזור התפריטים, האיזור העליון שמכיל את הלוגו, והאיזור התחתון.

סקיצה של האתר

סכמות אלו יעזרו לכם לקבוע מה אתם רוצים לראות באתר שלכם. האם העמוד הראשי יכיל פוסטים מלאים או רק את הפתיחה, האם תהיה אפשרות להגיב לפוסטים ? האם יש צורך להירשם על מנת לפרסם תגובה ? כיצד נראה עמוד ההרשמה ?

השלב הבא הוא בחירת השפה בה יכתב האתר. יתכן שתרצו לתרגל שפה חדשה או שאולי תרצו להישאר בתחום הנוחות שלכם, עם השפה העיקרית שלכם. php היא אחת השפות המובילות כיום לכתיבת אתרים, אך ניתן לשקול גם את ASP.NET שמתפתחת עם הזמן. כמו כן, ביחרו את בסיס הנתונים בו תרצו להשתמש. תוכלו להשתמש בקבצים רגילים(flatfiles) על מנת להגיע לדרישות מינימליות בשימוש במערכת שלכם. אפשרות סבירה יותר היא בחירה בבסיס נתונים התומך בשאילתות SQL , כמו Access, mySQL ו-MSSql.

על מה כדאי לשים לב לפני המעבר לשלב המימוש ?

תכנון מראש יעזור למערכת לתמוך בפונקציונליות הדרושה לאתר. יהיה קל יותר לכתוב את המערכת מההתחלה מאשר להוסיף את הפיצ'ר כתוספת.

היום השני – תיכנון בסיס הנתונים

לשם הדוגמה, נמשיך בשלב זה והבאים בבנית מערכת המוכוונת לניהול בלוג.

לאחר שאנו יודעים כיצד יראה האתר ומה יהיה בכל עמוד, ניתן לגשת ולתכנן את בסיס הנתונים. בלב כל מערכת לניהול תוכן תוכלו למצוא את הנתונים הבאים:

  1. כללי. טבלה שתכיל נתונים כלליים על הבלוג: שם הבלוג, כתובתו, קישור לקובץ הלוגו של האתר, מיהו מנהל האתר, כמה פוסטים יופיעו בעמוד הראשי, שפת האתר(עברית\אנגלית\ספרדית) וכל פרט אחר שתרצו לשנות באופן קל ומהיר ללא צורך בשינוי קוד המערכת.
  2. משתמשים. אלו יכולים להיות מנהלי הבלוג\אתר (מנהל יחיד או קבוצה של מנהלים), ובנוסף אנשים הרשומים לבלוג\אתר. טבלה זו תכיל בדרך כלל כינוי למשתמש, מספר יחודי עבורו, את שמו האמיתי, סיסמא, כתובת הדוא"ל שלו והאם הוא משתמש רגיל באתר או בעל הרשאות מיוחדות. כאן תוכלו להיות יצירתיים, אם האתר שלכם תומך למשל במתן ניקוד לכל משתמש בהתאם לרמת השתתפותו באתר, שימרו שדה לנתון זה.
  3. נושאים. פוסטים בבלוג בדרך כלל מסווגים לפי נושא, "בניית אתרים", "תיכנות", "כללי" ולכן טבלה שתכיל את רשימת הנושאים תשמש אותנו לצורך זה. בטבלה נרצה לשמור את שם הנושא, מספר יחודי עבורו ושדה שמתאר אותו בקצרה.
  4. פוסטים. הטבלה החשובה ביותר עבור הבלוג. השדות בטבלה זו יהיו כותרת הפוסט, כותרת משנית, מספר יחודי עבורו, הקדמה לפוסט, הפוסט המלא, תאריך פירסום ומספר המשתמש שכתב את הפוסט. ניתן להוסיף כאן את מספר הפעמים שהפוסט נקרא וכל רעיון אחר שעולה לכם לראש שיתאר טוב יותר את הפוסט.
  5. קישור בין פוסטים לנושאים. בטבלה זו כל כניסה תתאר קשר בין פוסט מסויים לנושא אחד. יהיו 2 שדות: מספר הפוסט ומספר הנושא. כך תוכלו לשייך פוסט למספר נושאים על ידי הכנסת מספר כניסות לטבלה. 6. תגובות. בטבלה זו ישמרו התגובות לכל פוסט. כדאי לשמור בה את מספר המשתמש שפירסם את הפוסט, את תאריך הפירסום ומספר הפוסט אליו הגיבו. כדאי לחשוב על הוספת אפשרות לסמן האם הפוסט מאושר או לא. כך תוכלו לעבור על כל התגובות לפני שהן עולות לאתר.

ישנן טבלאות נוספות שניתן ליצור, אך אלו יספיקו בתור הבסיס לאתר.

היום השלישי – כתיבת העמודים

כאן נכנס כישרון התיכנות שלכם לפעולה. אני ממליץ לשמור את הנקודות האלו בראש בזמן התיכנות:

  • הפרדה בין תוכן, קוד ועיצוב. בהתאם לשפת השרת בה אתם מתכנתים, נסו ככל היותר לשמור על הפרדה בין המרכיבים הללו של המערכת.
  • חסכו בפעולות על הנתונים(כמו סינון נתונים או פרישתם) ותנו לבסיס הנתונים לבצע זאת עבורכם.
  • "שברו" את הקוד כמה שיותר, אם יש פעולות שחוזרות על עצמן, ייצאו אותם לקובץ נפרד.
  • מדיי פעם, ודאו כי האתר עומד בתקני כתיבת קוד xhtml.

היום הרביעי – ספאם ואבטחה

על מנת שהאתר שתבנו לא יהפוך מוקד להתקפות, יש לשים לב לנושא האבטחה בזמן כתיבת הקוד. בכל קבלת קלט ממשתמשי האתר, או פנייה לבסיס הנתונים, ודאו כי הקלט שהוכנס אינו זדוני. אם ציפיתם למספר, ודאו כי זה מה שקיבלתם. התקפות אלו על בסיס הנתונים נקראות SQL Injection, הן קלות לביצוע ועשויות להוביל למחיקת הנתונים, שליפת הנתונים או שינוי שלהם ללא אישור.

הדבר הבא שיש להגן מפניו, הוא ספאם. תוכנות שנכתבו לשם כך(בוטים), ימצאו את אתרכם ויזהו כי ניתן לפרסם בו תוכן(למשל כתגובה). מהר מאוד תגלו כי לאתרכם מאות תגובות שמכילות קישורים לאתרים שונים ברחבי הרשת, או סתם חומר שיווקי מרגיז. השתמשו במנגנון CAPTCH על מנת לזהות בין בוטים למשתמשים לגיטימים.

היום החמישי – מערכת הניהול

ממשק הניהול של המערכת הוא מרכיב מרכזי בנוחות תיפעול האתר. ממשק זה יאפשר את הוספת התכנים החדשים, עריכת ומחיקת הישנים, ניהול המשתמשים, הגדרות האתר ולמעשה מטרתו לנהל כל אספקט של האתר ללא צורך בשינוי הקוד.

אחד הרעיונות שאני אוהב ליישם הוא ממשק ניהול המשולב בדפי האתר. כלומר במקום לרכז את כל אפשרויות הניהול בעמוד אחד, נבזר את הניהול לכלל דפי האתר. לאחר התחברות לאתר וזיהוי מנהל, יופיע ליד כל פוסט אפשרות עריכה או מחיקה. בעמוד של נושא מסויים תופיע האפשרות להוספת פוסט חדש, ליד כל תגובה תהיה אפשרות למחוק\לערוך אותה. ליד הלוגו, תהיה אפשרות לשנות אותו לקובץ אחר, או אפשרות להעלות תמונה חדשה מהמחשב.

עריכה בצד הקדמי

כתיבה בצורה כזאת, מאלצת אותנו לחזור לשלב כתיבת קוד עמודי האתר, ולהוסיף בהם את הניהול. אני מצאתי שפיתרון זה מאפשר לי לשנות את האתר באופן קל יותר ברגע שעולה לי רעיון בזמן דיפדוף בו.

בנושא כתיבת הפוסטים, אני ממליץ על עורך הטקסט TinyMCE לעומת האחרים ברשת. זוהי למעשה מעין אפליקציית WORD קטנה שבה ניתן לכתוב את התוכן ולשמור אותו אל בסיס הנתונים. לאחר מעבר על מספר רב של עורכים כאלו ברשת, גיליתי ש-TinyMCE מספק קסטומיזציה מלאה ועובד מצויין.

היום השישי – בדיקות

זהו השלב לוודא כי כל מה שכתבנו עובד כמתוכנן. כדאי להכין רשימת בדיקה שתכיל את כל האפשרויות שהמערכת מספקת, החל מכתיבת פוסטים ועד עריכת פרטי משתמש ולהשתמש ברשימה זאת על מנת לבדוק כי הכל פועל כשורה. אם תוכלו לגייס מספר אנשים נוספים שיעזרו לכם בשלב הבדיקה, תוכלו לגלות בעיות שאתם עיוורים אליהן.

היום השביעי – תוספות

עכשיו כשיש לכם בסיס טוב לבנות עליו, תוכלו לשלב בו תוספות ושיפורים. בוודאי עלו בראשכם רעיונות בזמן שבניתם את המערכת. רעיונות לבלוג שיכולים לצוץ הם הזנת RSS, מפת אתר, הרשמה במייל לעידכוני פוסטים, מערכת דירוג פוסטים, מערכת הצבעות ועוד.

אל תלמדו מטעויות, תלמדו מהטעויות שלי

הנה רשימת המסקנות אליהן הגעתי בזמן בניית המערכת שלי:

  1. האם זה היה שווה את המאמץ ? אני יכול להעיד שיכולתי להסתפק ב-WordPress לפרויקט שלי למרות שנהנתי ולמדתי לכתוב את המערכת בעצמי. כדאי לבחון מראש את מה חסר לכם ולראות אם ניתן להרחיב מערכת קיימת.
  2. שמרו על הקוד נקי מקטעים Hardcoded. אל תשאירו בקוד אפילו דבר אחד שתרצו לשנות, לא את מספר הפוסטים שיוצגו בעמוד הראשון ולא את רשימת הלינקים שיופיעו בתפריט. הטיפ הכי טוב הוא לזכור שכל פעם שמופיע מספר או מחרוזת מפורשת (כמו "Popular Posts") בקוד, צריך לבדוק אם נרצה לשנות אותו. אם כן, נעביר אותו לבסיס הנתונים.
  3. ריבוי שפות. את התמיכה בריבוי שפות מומלץ לממש בעזרת קובץ שפה המגדיר משתנים עם משמעות. מי שירצה(אתם או אחרים) יוכל לתרגם את הקובץ הזה בלבד לכל שפה. הטעות הבסיסית ביותר שאני עשיתי בנושא זה היא שניתן להגדיר קידוד לאתר. עדיף היה לשמור על כולו בקידוד Unicode ולמנוע בעיות כאשר משלבים יותר משפה אחת.
  4. תמיכה בעברית ובשפות אחרות הכתובות מימין לשמאל. תמיכה זו יכולה להיות ממומשת בעזרת קובץ CSS שמכיל את עיצוב האתר. האחריות תעבור מהקוד אל העיצוב, ואם אתם מתכנתים שאינם מעצבים (כמוני) – טוב שכך.
  5. תנו למערכת שלכם כנפיים. שחררו את הקוד שלכם לאנשים אחרים וכך תקבלו פידבקים(ואולי גם שיפורים) ורעיונות לשיפורים ותוספות. בעת כתיבת המערכת, כיתבו אותה כך שתהיו גאים לשחרר אותה לאנשים אחרים וכך תמנעו מלעגל פינות והמערכת תשתפר פלאים.
  6. תיעוד. כאשר כותבים קוד, הכל נראה פשוט, קריא ומובן. בדיוק חודש אחרי, הוא נראה מסובך, לא קריא ובלתי מובן בעליל. לכן השקיעו דקה על מנת לכתוב מה המטרה של כל קטע קוד. אין חובה להתעמק בכל פקודה, אלא רק להבהיר מהי הבעיה שהקוד פותר.

מבט אחורה וקדימה

על השאלה "האם יש טעם בבניית מערכת לניהול תוכן מהיסוד?" לא ניתן לענות בכן או לא. יש לבדוק האם יש צורך אמיתי והאם הזמן הדרוש ללמידת מערכת קיימת ושינויה קצר מזמן בניית המערכת החדשה. בכל מקרה, תזכרו שחליפה שתפורה במיוחד לכם, תראה טוב יותר מאחת שקניתם מהמדף.

הכיוון שאליו הייתי רוצה לראות את המערכות מתפתחות הוא כיוון מבוזר. יהיו מערכות רבות שכל אחת מהן תספק שירות אחר, אחת תספק שירות ניהול משתמשים, אחת תספק שירות עידכונים במייל, אחרת תספק שירות סינון ספאם ועוד. כל אחת תציע את שירותיה לאחרות ועל מנת לבנות מערכת נוכל לאסוף את החלקים הרצויים ולהדביקם יחדיו למערכת אחת המותאמת לנו.

טל ברזניצקי, מתכנת כבר מעבר לעשור במספר שפות תיכנות, נמצא בשלבי טירונות בבנית אתרים וכותב באתרו קטע קוד בנושאי תיכנות, בנית אתרים ואינטרנט.

קרא פוסטים נוספים בנושא זה:

שתף את הפוסט בטוויטר

22 תגובות »

  • מאת דודו:

    נראה לי שהסיבה האמיתית בגללה מתכנתים ממציאים מחדש את הגלגל היא שזה התחביב שלהם…
    לגבי הסיבה שציינת – אתרים שדומים מדי זה לזה – אני חולק עליך. ברוב מערכות ניהול התוכן המודרניות נושא העיצוב גמיש לחלוטין. המערכת לא כופה עליך שום תבנית, כך שאין קשר בין מערכת ניהול התוכן לקוד ה-html שמופיע באתר.
    סיבה טובה בעיני לכתיבת מערכת חדשה היא הוספת תכונה (או צירוף של תכונות) שלא קיימת במערכות אחרות, וכן כפי שציינת, רצון להכיר מקרוב את התוכנה.

  • [...] בניית מערכת ניהול תוכן מההתחלה | We CMS למה לבנות מערכת תוכן חדשה? אין עושים את זה בשבעה ימים? ארז וולף בפוסט מצויין. (tags: cms programming DIY) //OBSTART:do_NOT_remove_this_comment var OutbrainPermaLink="http://www.dakars.info/general/links-for-2008-06-25/"; var OB_demoMode = false; if(typeof(OB_Script)!='undefined'){ OutbrainStart(); }else{ var OB_Script = true; var OB_langJS ="http://widgets.outbrain.com/lang_he.js"; document.write (""); } //OBEND:do_NOT_remove_this_comment נהניתם מהפוסט ? כדאי להרשם לעדכוני RSS ולקבל הכל ישירות. [...]

  • בהחלט מאמר מעמיק ואינפורמטיבי, והדיון התיאורטי בבניית מערכות ניהול תוכן הוא מרתק, אבל נקודת המוצא שגויה מהיסוד. ב-99% מהמקרים, אלא אם כן עצם בניית המערכת מהווה יעד בפני עצמה, בניית מערכת חדשה מהייסוד היא טעות חמורה שלעולם אי אפשר יהיה לחזור ממנה, וההמלצה להקים מערכת כזו לכל מטרה מלבד מחקר היא חסרת אחריות.

    הקביעה "אם אתם רוצים יחודיות, אתם רוצים מערכת חדשה", היא, אם תסלח לי, שטות מוחלטת, שמנותקת לחלוטין מהמציאות. אם כבר הצעת ללמוד מהטעויות שלך – זו חתיכת טעות חינוכית, ונראה שהגעת למסקנה הזו בעצמך לקראת הסוף.

  • מאת מושון:

    אני מסכים עם רן.
    אם אתה רוצה להרחיב את האופציות של מערכת קיימת, בחר אחת שמאפשרת הרחבות (plug-ins) תמצא לרוב שרובן עושות את זה. במקרים של מערכות פופולריות כמו וורדפרס, נדיר שתצליח לחשוב על פלאג אין שאף אחד עוד לא כתב, לרוב הקונפליקט הוא לא האם לכתוב חדש אלא איזה מבין ה-10 לבחור. במקרה שכן מעניין אותך לתכנת פלאג אין משלך, תוכל למצוא עזרה בבניה ואולי אף בטא-טסטרים שידווחו על באגים ואולי אפילו יתקנו אותם.
    הבעיה האמיתית של CMSות קיימות היא עקומת הלמידה שהן מצריכות, חוסר סבלנות היא לרוב הסיבה המרכזית שבגללה מפתחים מוותרים על לימוד המערכת החדשה או לחילופין הולכים על ברירת המחדל.ֿ
    ההצעה שלי:

    קודם לשרטט את צרכי האתר ברמת הפיצ'רים
    אח"כ לבחור את ה-CMS שנותן מענה מלא לעניין (בשאיפה מתוך CMSות שאתה מכיר ומחבב, תחפש אצל ארז, בטוח תמצא משהו)
    אחרי שבחרת CMS נסה לחפש טמפלייטים קיימים אשר נראים כמה שיותר שונה מהטמפלייט דיפולט על מנת שתוכל להשתחרר מכבלי הדיפולטיות (דוגמה). למד מה עשו שם וקבל רעיונות.
    אל תתחיל לעבוד מטמפלייט מעוצב כיוון שלא תצליח להתרחק ממנו מספיק. חפש טמפלייט ג'נרי, פשוט (דוגמה), או שממש תתחיל מאפס.
    סברה: אחת הסיבות שוורפרס זכתה לכ"כ הרבה טמפלייטים (מעבר לפשטות שבכתיבתם) היא שהתבנית הדיפולטית היא ממש חסרת אופי וצועקת "תשנו אותי" (כנראה שאנשים שמעו אותה ומשנים). זו גם הסיבה לדעתי שכ"כ הרבה אתרי דרופל נראים כמו הדיפולט וסובלים מחוסר השראה מגמתי.

    בכל מקרה, תודה על הסקירה ועל העלאת הדיון הדי חשוב הזה.

  • מאת טל:

    כמו שכולכם אמרתם, גם אני הגעתי למסקנה(אפילו רשמתי אותה ראשונה במסקנות) שכבר יש מערכת מוכנה שהייתה עונה לצרכים של האתר שבסוף יצרתי – אתר בצורת בלוג. לעומת זאת, באתר אחר שלי בו מוצגים קטעי וידאו, לא מצאתי מערכת שתתאים לי בדיוק, ואני שמח על כך שבניתי את תשתיות האתר בעצמי. כמו שרן אמר, צריך לבדוק לפניי אם אתם ב-1% שזקוקים לצורך שונה ממה שכבר קיים.

    אני עדיין מחזיק בדעה שרוב האתרים המבוססים על אותה מערכת דומים אחד לשני יותר מדיי, למרות היכולת לערוך אותם. המגיב לפניי סיפק הסבר מצויין איך כדאי לברוח מהמלכודת הזאת, על ידי בניית הטמפלייט מנקודת ההתחלה ולא מטמפלייט מוגמר.

  • מאת זהר:

    אין היום שום סיבה הגיונית לבנות מערכת ניהול תוכן מאפס.

    בניית מערכת ניהול תוכן טובה (ויחודית) לא אורכת שבעה ימים, כי אם שבע שנים. אני לא מכיר אף תוכנה שמרגע סיום כתיבתה, נפסקת התחזוקה שלה. קוד יש לתחזק, בדיוק כפי שיש לתחזק בית מיד עם סיום בנייתו. יש בלאי, יש טכנולוגיות חדשות, יש פריצות, ויש הרחבות.

    זה לא מקרה שמערכות ניהול התוכן הטובות ביותר כיום, דרופל, פלון, ווררדפרס, ג'ומלה ואחרות, לא נכתבות בידי מתכנת בודד בשבעה ימים, אלא ע"י אלפי מתכנתים, שממשיכים בפיתוח יום יום.

    מערכות ניהול תוכן טובות מאפשרות לך להתרכז בתוכן ובעיצובו, ולא בתחזוקת הקוד. יתרה מכך, הן מאפשרות לך להוסיף תכונות חדשות לאתר בלי מאמץ.

    לגבי הכיוון שאליו טל רוצה לראות את עולם ניהול התוכן מתפתח: מערכת ייעודית לכל מטרה – גם זו טעות תפישתית לטעמי, כיוון שהיא רק מעמיסה על מנהל האתר – במקום להתמודד עם מערכת אחת, הוא נאלץ להתמודד עם 10 מערכות. יחד עם זאת, השימוש במערכות צד שלישי להשגת מטרות שונות, כגון סינון ספאם, אירוח מדיה, ניהול רשימות תפוצה ואחרות; שימוש זה הוא נכון ומתבקש בעולם האינטרנט של היום, כל עוד ההתממשקות למערכת ניהול התוכן היא קלה – ושוב, כאן מצטיינות המערכות הקיימות.

  • מאת מושון:

    סיבה נוספת וחשובה לא פחות לשימוש במערכות קיימות (ובעיקר פתוחות) היא יחסי ספק/לקוח.
    אם הרמת אתר על מערכת שבנית לבד, לאנשים אחרים יהיה קשה מאוד להכנס אל הקוד שלך ולהבין מה רצית. תיעוד בקנה מידה של אדם אחד הוא אף פעם לא מספיק. מה שקורה בסופו של דבר הוא שהלקוח נשאר בן ערובה של ספק השירות – זה לא שירות טוב ללקוח ובמקרים רבים גם לא לספק השירות כיוון ש(בעיקר בארץ)לעיתים קרובות מדי הלקוח בטוח שברגע ששילם לך על האתר, אתה שלו לנצח. מומלץ מאד להשאיר דרך מוצא מהסבך הזה. מה עוד שאם בנית את המערכת מ-0 קרוב לודאי שתמצא את עצמך נתקל בבאגים לבד לראשונה ומתקן אותם זמן רב אחרי סיום הפרויקט, מה שעלול להפוך את הפרויקט ללא ריווחי בשבילך ומתסכל עבור הלקוח.

    כדי לא להציג את העניין כשחור ולבן, יש מקרים מוצדקים להתחיל משהו מ-0. אני הייתי מאד ספקן לגבי הפרויקט של מאיר קריחלי – להק, מערכת ניהול תוכן חדשה מ-0. אבל באירוע בגראז' גיקס הוא הצליח לשכנע אותי שאת שילוב הדגשים שהוא צריך הוא לא יכול להשיג כרגע משום מערכת אחרת גם לא ע"י הרחבתה:

    מחוייבות לריבוי שפות וbidi מהרמות הכי בסיסיות של המערכת
    הרחבה של מודל הוויקי לכלל האובייקטים במערכת ברמת חיווט בין שפות

    הרחבה של מודל הוויקי לכלל האובייקטים במערכת ברמת עריכה משותפת ושמירת גרסאות
    שימוש בדג'אנגו – פריימוורק על בסיס פייתון
    (אלה הכמה שאני זוכר)

    בכל מקרה, כפי שדוסקס ארוכות בגראז', להק שואפת להפוך להיות פרויקט שיפותח על ידי קהילה ולא פתרון יחודי שמספק מפתח אחד בלבד. אם היא תצליח ואני כולי תקווה שזה יהיה המצב, הדיבור על להק יהיה ברובריקה של לבחור מערכת קיימת ולא ברובריקה של להתחיל אחת מ-0.

  • מאת יוני כץ:

    זה נכון לגבי מתכנתים ששולטים בתחום ובעלי שליטה מעולה בשפת תכנות
    בשבילי בתור אחת שלא שולט טוב ב PHP או ASP

    אני מעדיף את המערכות תוכן המוכנות..

  • חבל להשקיע במערכת עצמאית שנבנת לבד… פשוט תלמדו HTML ו CSS ברמה גבוהה וככה
    תצליחו לעצב טמפלטים על כל מערכת קוד פתוח ולהנות מהייתרונות שלה…

    תאמינו לי שגם וורדפרס יכול להראות כמו מייספייס אם רוצים!

  • מאת kisin:

    אני משתמש כבר שנים בכל מערכות CMS המוכרות:
    sharepoint
    drupal
    joomla
    codeigniter (framework)
    zend frameword
    ולאחרונה ממש מעט wordpress

    אני יכול לומר לכם מהנסיון שלי שלכל מערכת יש את היתרונות והחסרונות שלה. אבל יותר חשוב מזה, עם כל מערכת ניתן ליצור אתר ברמה גבוהה ואתר ברמה נמוכה. הכל שאלה של רמת הידע שיש לך במערכת עצמה.

    הכי חשוב, המערכות המוכנות נותנות לך הרבה דברים חשובים עוד לפני בכלל שניגשים לאתר עצמו:
    אבטחה ברמה גבוהה
    הזדהות
    SEO
    ניהול משתמשים
    התנהלות מול מסד נתונים
    ניהול cache
    ועוד הרבה דברים שיקחו ממך ה-ר-ב-ה זמן פיתוח. ורק אחרי כל זה תיגש בכלל לבנייה של האתר עצמו.

    תכלס ההבדל המשמעותי מבחינת הלקוח (או הגולש באתר) הוא ברמת השימושיות של האתר וברמת הגימור והעיצוב. לכן חשוב מאוד ללמוד לעצב (html, css, javascript frameworks וכדומה) ולדעת ליצור אתר שמיש.
    בשביל יכולות הטכניות של האתר עצמו נשתמש באחת מהמערכות CMS המוכנות והידועות (או הידועות פחות).

    אני אשמח לענות על שאלות לגבי כל מערכת ספציפית במידה ואני אוכל.
    בהצלחה לכולם

  • מאת יאיר:

    לארז שלום,

    לאחרונה "נתקלתי" באתר http://www.pmail.co.il
    הם נותנים שירות של כתובת אימייל עם מספר הטלפון שלך [או כל מספר שתבחר] – לא ביג דיל
    ואז כל מה שישלחו לכתובת הזו – תגיע לכתובת אי מייל שתבחר.

    נראה לי שזה יכול להתאים לי להציע לגולשים באתר שלי (גם קידום מפוקפק לאתר שלי :-) וגם לא לוקח לי שטח מקום בשרת [שנותן לי כתובות אימייל ללא הגבלה] – יש לך מושג איך עושים את השירות הזה?

  • מאת אביב:

    איזו מערכת ניהול תוכן טובה ל SEO?
    מה אתם ממליצים?

  • מאת אחד:

    אפשר לצמצם את זה ל3 ימים בעזרת django שמספק לך הכל(ממשק ניהול מותאם לפי התכנון של הDB, ניהול משתמשים והרשאות, ORM לDB, מערכת טמפלטים חזקה):
    1. יום ראשון, תכנון מסד הנתונים בעזרת הORM של django, בסוף היום יש לה גם DB וגם ממשק ניהול מוכן שהלקוח יכול להכניס תכנים.
    2. עיצוב האתר יום א', תכנון הדפים, ובניית הviews, יום זה כולל שילוב של מעצב ומתכנת, המעצב עושה דיזיין לדפים המתכנת לפי העיצוב בונה הviews ששולפים מהDB ומעבירים לטמפלט את הפרמטרים.
    3. עיצוב האתר יוןם ב', בונים את הטמפלטים(מתכנת + מעצב, אני הייתי עושה את זה בשיטת הpair-programming שבו המעצב עושה את הHTML והמפתח עושה לו code review תוך כדי, בחלקים שבו צריך מידע דינאמי המתכנת לוקח את המושכות ועושה את החלק ה"תיכנותי" בטמפלט והמעצב מבקר אותו[הטמפלטים ממש פשוטים ככה שגם מעצבים יכלים לעשות את החלק הזה אבל כדי לצמצם זמן עדיף לעשות ביחד])

    כל זה נותן לך אבטחה, יציבות של django,אתה לא מתעסק עם דברים מיותרים ולא חוזר על עצמך.
    בנוסף הדבר החזק ביותר בdjango שיש caching אוטומטי מה שאין לך בתכנון שלך ובמצב של הפצצה לדוגמה מdigg/slashdot/ynet וכד' האתר מבוסס django על חומרה ותוכנה שהוגדרה על יד מקצוענים יעמוד בזה, והאתר שלך לא יעמוד בזה.

  • מאת אחד:

    שחכתי לספר קצת על django, שהיא framework מבוסס python, יש שיגידו שדומה ל rails, אני אישית עצלן ועם הפרעות קשב, ולא החזקתי יותר מידי זמן בלמידה של rails גם בגלל השפה וגם בגלל שהוא מורכב מידי בשבילי.
    django היא kiss, היא פשוטה, ובו זמנית מספיק גמישה, אתה יכול לדרוס את הממשק ניהול לדוגמה ולשים טפסים משלך אם אתה צריך משהו custom made.
    היא תוכננה מראש למערכות עיתונים אבל היום היא משמשת הרבה אתרים שמתמודדים עם תעבורה גבוהה כמו הוושינגטון פוסט, במידה והאתר שלך לא עומד בתעבורה אתה יכול להתחיל לעשות scale-up, בשלב הראשון להתקין שרת cache נפרד, בשלב הבא להתקין שרת שמשרת דפים סטאטיים בנפרד, אחרי זה להפריד את הDB, אם כל זה לא מספיק אז להוסיף שרת proxy שמפריד את העומס על כמה שרתי ווב, ואם זה גם לא מספיק אז כנראה הצוואר בקבוק הוא הDB, אתה יכול להתחיל לעשות scale-up לDB עצמו(כמובן שתלוי בDB עצמו, לאורקל יש כלים חזקים בנושא, לpostgres יש כמה הרחבות שנותנות לך replication וmysql אאלט יש בגירסה האחרונה שלו תמיכה בreplication).
    איזה סוגים של scaleup יש לDB? אני לא DBA אבל אני מכיר בעיקר replication שזה בעצם שכפול המסד נתונים ככה שיהיו כמה שרתי שליפה ובד"כ שרת אחד לכתיבה, כמובן שבכל זמן הDB יראה אותו דבר בכל השרתים אבל אתה תוכל לשלוף על כמה שרתים מסויימים ולעשות הכנסות ועדכונים רק בשרת אחד(או כמה שרתים).
    לאורקל יש גם אפשרות לcluster לא יודע עד כמה זה מתאים לישומיי ווב.

    תראה לי CMS שמאפשר את זה בצורה שקופה בPHP?

  • האם המערכת django תומכת בעברית?

  • django היא מערכת עם תרגום לעברית?

  • מאת שיפוצים:

    לא מבין מה זה django האם אפשר לקבל הסבר פשוט? תודה. 

  • אני כבר כמה שנים עובד עם המערכת של לייב סיטי
    זה אמנם לא הכי זול …אבל אין לה תחליף
    תאמינו לי – אני מכיר את וורדפרס ועוד רבות אחרות
    למערכת של לייב סיטי אין תחליף

    emi filter

  • אין כמו המערכת של לייב סיטי
    כדאי לכם לבדוק

    emi filter

  • מאת אסי כהן:

    למה תמיד נדחפים אנשי מכירות!!!
    השאלה שלי האם אפשר להפוך את מערכת ניהול התוכן של המערכות הקיימות, לידותית יותר למשתמש הפשוט

  • מאת סיון:

    אחלה מדריך :)

  • מאת יוסי:

    בס"ד
     
    בדיוק היום התחלתי להפיץ מערכת שסיימתי לבנות.
    הסיבות שלי היא כמו כותב המאמר אני אוהב לדעת הכל על הקוד שאני כותב.
    המערכת ניתנת לשימוש חינם תוכלו להתרשם באתר.
    rtlx.co.il
    שמחתי על המאמר ואשמח לחברה מתכנתים שירצו לעזור ולשפר את המערכת.

הוסף תגובה!

עליך להיות מחובר כדי להוסיף תגובה.

127 queries in 0.218 seconds.