WSDL מקומי עדיין יכול לשלוח את SoapClient אל הרשת
עקבו אחר ייבוא WSDL ו-XML Schema עקיף כאשר הגדרת שירות מקומית עדיין מערבבת מסלולי proxy פנימיים וחיצוניים.
service.wsdl מקומי עדיין יכול לגרום ל-SoapClient להביא מסמכים מרוחקים בזמן הבנייה. הפיכת הקובץ הראשון למקומי מסירה רק את ההורדה הראשונה הזו:
local service.wsdl
→ internal Common.xsd
→ external Types.xsd
→ another schema location
התחילו מהשליפה הראשונה שנכשלה, לפני קריאת העסקים הראשונה ב-SOAP. רשמו כל ייבוא WSDL וכל schema location, כולל המסמכים שאליהם הם מפנים בתורם. שמרו את כתובת הבסיס או הנתיב שבהם משתמשים לפתרון כל הפניה יחסית. הפרידו בין מארחים פנימיים לבין משאבים שבאמת זקוקים ל-proxy החיצוני.
proxy של SoapClient מפורש יכול לשלוח schema פנימי דרך מתווך עם תצוגת DNS או מדיניות גישה אחרות. משתנה no_proxy ברמת התהליך אינו מוכיח שמסלול הטעינה הזה קורא אותו. השתמשו באפשרויות המתועדות לגרסת ה-PHP שלכם; מתן שם אפשרות על שם משתנה סביבה אינו יוצר בורר לכל ייבוא.
כדי לפרוס הגדרות באופן מקומי לחלוטין, השיגו את הגרסאות המאושרות של מערך התלויות כולו, עדכנו את מיקומי הייבוא הרלוונטיים לחבילה המקומית ושמרו על בסיסי הנתיבים היחסיים שלהם. נסחו גרסאות של המסמכים האלה יחד כדי ש-WSDL שורש חדש לא ישתמש בטיפוסים מיושנים.
הניחו למזהי namespace. הם עשויים להיראות כמו כתובות URL, אך הם מזהים את אוצר המילים של ה-schema ולא אומרים לטוען מהיכן להביא קובץ. החלפתם עלולה לשנות את חוזה השירות.
בדקו מחדש את הבנייה כשמצב המטמון מתועד: הגדרות שמורות במטמון יכולות להסתיר תלות חסרה במכונה אחת. עקיפת כתובת השירות חלה בשלב מאוחר יותר, ו-__doRequest() מותאם מטפל בחילופי SOAP; אין להניח שמי מהם משכתב או מיירט את כל הורדות ה-schema בזמן הבנייה.