מ-Lovable ל-WordPress: פרויקט שהומר לתבנית אמיתית

דוגמה להמרה מ-Lovable ל-WordPress, פתוחה משני הקצוות

כל מה שבהמשך מתאר המרה שבאמת הרצנו. המקור הוא אפליקציית Lovable: bruce-banner.lovable.app, תיק עבודות של צלם. התוצאה היא bruce.html2wp.dev, שרץ על WordPress. אפשר להיכנס לממשק הניהול שלו ב-/wp-admin עם שם המשתמש demo והסיסמה demo.

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

עוד שתי המרות של Lovable פתוחות באותו אופן. ראשית, spark-remix-kindred.lovable.app הפך ל-terra.html2wp.dev, חנות סריגים על WooCommerce. שנית, bloom-echo-remix.lovable.app הפך ל-soria.html2wp.dev, אתר של צלם חתונות. בכל שלושת האתרים, פרטי הכניסה לממשק הניהול של WordPress הם demo / demo.

מה המחשב שלכם צריך כדי להמיר מ-Lovable ל-WordPress

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

• Node 20 ומעלה לבנייה ולסקריפטים המקומיים.
• Python 3 עם החבילות Playwright ו-Pillow. Playwright מפעיל דפדפן אמיתי, וכך אפליקציית React הופכת ל-HTML.
• Docker עם הפקודה docker compose. הוא מפעיל WordPress זמני במחשב שלכם, והממיר בודק שם את התבנית לפני שאתם רואים אותה.
• php-cli, כי כל קובץ PHP עובר בדיקת תחביר לפני שהוא נכנס ל-ZIP.
• jq, curl, bash ו-tar. ה-WordPress שאליו ממירים צריך להיות בגרסה 6.6 ומעלה.

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

התקנת התוסף

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

Claude Code

/plugin marketplace add iOSDevSK/html2wp-cc-plugin
/plugin install html2wp@html2wp

ואז, פעם אחת, בטרמינל:

python3 -m playwright install chromium

Codex

codex plugin marketplace add iOSDevSK/html2wp-codex-plugin
codex plugin add html2wp@html2wp

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

איך מעבירים את פרויקט ה-Lovable לדיסק שלכם

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

לכן הקלט הוא תיקייה. Lovable מסנכרנת את הפרויקט שלכם למאגר GitHub. חברו אותו, שכפלו אותו (clone), ויש לכם את הפרויקט במחשב. לא משנה איך נראה ממשק Lovable החודש, המאגר הוא מה שאתם צריכים: אותם קבצים שמהם Lovable בונה את האתר.

git clone https://github.com/<you>/<your-lovable-project>.git
cd <your-lovable-project>

לא צריך להריץ קודם npm install או בנייה. ההמרה עושה את זה בעצמה.

אמרו "convert this project"

בתיקייה הזו, כשהסוכן שלכם פתוח, הקלידו:

/html2wp:html2wp

convert this project

ל-Codex אין פקודת סלאש. במקום זה כתבו לו convert this project into a verified WordPress block theme, והוא ימצא את ה-skill בעצמו. עם Claude Code או Codex, המשפט הזה הוא כל ההוראה. לא כותבים קובץ הגדרות ולא בוחרים פקודת בנייה.

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

מה קורה ל-React כשממירים מ-Lovable ל-WordPress

זה השלב שפרויקט Lovable מוסיף.

לאפליקציית Lovable ישנה (React ו-Vite) יש index.html אחד. ה-body שלו הוא רכיב ריק שאפליקציית ה-React נטענת לתוכו, ועוד תגית script, כך שאין שם מה להמיר. קודם הממיר בונה את הפרויקט. אחר כך דפדפן אמיתי עובר על כל נתיב בזמן שמקליט צופה בו. התוצאה היא HTML שטוח לכל נתיב, בדיוק מה ששאר התהליך צריך. פרויקט חדש יותר על TanStack Start כבר מרנדר את העמודים בשרת. הממיר בכל זאת בונה אותו ועובר על כל נתיב באותה דרך.

מה המקליט לוכד

• מצב שקיים רק אחרי ש-JavaScript רץ. אקורדיונים פתוחים, תוכן של תפריטים נפתחים, classes שסקריפט משנה. המקליט שומר אותם כנתונים על הרכיבים, ו-runtime קטן וגנרי מנגן אותם מחדש. אף אחד לא כותב אותם ידנית מהזיכרון.
• ספי גלילה, עד הפיקסל. כותרת שמשתנה ב-scrollY > 40 משתמשת במספר שמישהו המציא. המקליט מוצא אותו ומחשב בדיוק איפה הוא נמצא. ניחוש מעוגל היה משנה את הכותרת ברגע הלא נכון, לתמיד.
• יחסים של "רק אחד יכול להיות פתוח". פותחים את A, ואז את B. האם A נסגר? הקלטה של כל רכיב לבד לא יכולה לדעת, ולכן המקליט בודק את זה בנפרד.
• אנימציות כניסה בגלילה שורדות. המקליט לוכד אותן, והתבנית מנגנת אותן בדיוק כמו המקור. התוכן נשאר גלוי בלי JavaScript, רכיב מוסתר רק בזמן שה-runtime רץ, ועם prefers-reduced-motion התבנית מדלגת על האנימציה. את ההתאמה של 1:1 אנחנו מודדים במצב מנוחה, אחרי שהאנימציות מסתיימות.

מה הוא לא מזייף

• התנהגות שהוא לא הצליח להקליט נכנסת לרשימה. לכל עמוד יש רשימה משלו. קראו אותה.

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

הבדיקה שאי אפשר לדלג עליה

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

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

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

התקנת התבנית

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

ב-WordPress היכנסו אל עיצוב ← ערכות עיצוב ← הוספת ערכת עיצוב ← העלאת ערכת עיצוב (Appearance → Themes → Add New → Upload Theme), בחרו את ה-ZIP והפעילו אותו. התבנית עומדת בפני עצמה. עמודים, בלוג, טפסים, תפריטים, SEO והפניות הם כולם הקוד שלה. היא לא צריכה תוסף כדי לרוץ ואף פעם לא פונה לשרת שלנו.

עריכת האתר אחרי ההמרה מ-Lovable ל-WordPress: שלוש דרכים

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

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

Lite או Pro, אם בוחרים ב-Visual Edit

צ'אט ה-AI ב-Pro רץ על מפתח API משלכם. אנחנו לא מוכרים לכם טוקנים, ואת עלות השימוש בהם אתם מסדירים ישירות מול הספק שלכם.

Lovable או WordPress? לא חייבים לבחור

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

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

כמה עולה המרה מ-Lovable ל-WordPress ומה היא מסרבת לעשות

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

רישיון Pro מסיר את מגבלת העמודים והופך את ההמרות וההרצות החוזרות לבלתי מוגבלות. הוא גם מוסיף את השלב שהופך חנות ל-WooCommerce. השלב הזה בכלל לא קיים בגרסה החינמית: האפליקציה דוחה לגמרי המרה חינמית של אתר עם חנות, במקום לבצע חצי ממנה. Pro עולה 49 € לחודש או 490 € לשנה, והמחירים נמצאים בעמוד המחירים. בזמן הבטא התשלום הראשון זול ב-30% והמפתח מגיע באימייל.

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

מדריך שלב אחר שלב לכל התהליך נמצא בתיעוד של אפליקציית html2wp. שלוש המרות ה-Lovable שאפשר לפתוח משני הקצוות נמצאות בדוגמה שבתחילת המאמר.