config\/xml\/<\/code><\/pre><\/div>The most important ones are:
- must_have_modules_list.xml<\/span> \u2013 list of modules marked as \u201emust have\u201d by PrestaShop<\/li>
- modules_native_addons.xml<\/span> \u2013 list of native modules available in Addons<\/li>
- default_country_modules_list.xml<\/span> \u2013 suggested modules for a specific country<\/li>
- trusted_modules_list.xml<\/span> - List of trusted modules verified by PrestaShop<\/li><\/ul>These files do not affect the store's frontend or order processing. They are used solely for displaying information in the admin panel's modules section.
An XML error appears when there's a problem with the structure or syntax of an XML document. It typically occurs during the parsing or processing of the XML file by software, such as a web browser, an application, or a server.\n\nHere's a breakdown of what an XML error looks like and where it can appear:\n\n**What an XML Error Looks Like:**\n\nXML errors are usually reported by the software that is trying to read the XML file. The message will typically indicate:\n\n* **The nature of the error:** This could be a \"syntax error,\" \"parsing error,\" \"malformed XML,\" \"invalid character,\" \"unexpected end of file,\" etc.\n* **The location of the error:** This is crucial for debugging. The error message will usually point to:\n * **Line number:** The specific line in the XML file where the error was detected.\n * **Column number:** The position on that line where the error occurred.\n * **Error code (sometimes):** A specific code indicating the type of problem.\n* **A description of the problem:** A brief explanation of what is wrong (e.g., \"element is not closed,\" \"attribute value is not quoted\").\n\n**Common examples of specific error messages might include (these vary by parser):**\n\n* `XML parsing error: '...' is not followed by '>'`\n* `Error: Unclosed token.`\n* `XML validation error: Element '...' is not closed.`\n* `Error near line 10, column 5: Expected '>', but found ' '`\n* `Fatal Error: The element type \"...\" must be terminated.`\n\n**Where XML Errors Appear:**\n\nXML errors can appear in various contexts, depending on how and where the XML is being used:\n\n1. **Web Browsers:** When you try to open an XML file directly in a web browser, if the XML is malformed, the browser will display an error message along with the line numbers indicating the problem. This is often the first place developers encounter XML errors.\n\n2. **Web Servers\/Applications:**\n * **API Responses:** If a server is supposed to return data in XML format but fails due to an error in its XML generation, the client application receiving the response will get an XML parsing error.\n * **Configuration Files:** Many web applications use XML for configuration. If a configuration file is invalid, the application will fail to start or encounter errors during its operation.\n * **Data Exchange:** When applications exchange data using XML (e.g., SOAP messages), an error in the XML structure of the message will cause the receiving application to report a parsing error.\n\n3. **Desktop Applications:** Applications that read or write XML files for data storage, settings, or interoperability will report XML parsing errors if the files they encounter are invalid.\n\n4. **Databases:** Some databases store XML data. If you try to import or query XML data that is malformed, the database system will flag it as an error.\n\n5. **XML Editors and IDEs:** Development environments and specialized XML editors will often perform real-time validation as you type. They will highlight syntax errors directly in the editor, often with red squiggly lines and pop-up error messages.\n\n6. **Command-Line Tools:** Tools like `xmllint` or other XML parsers used in scripts will output error messages to the console when processing invalid XML.\n\n**In summary, an XML error is a notification that an XML document violates the rules of XML syntax or structure, and it appears within the software attempting to interpret that document.**<\/h6>The error most often appears directly in the admin panel \u2013 in the tab Modules<\/strong> or after entering Module Manager<\/strong>. Messages can look like this:
Error found: Start tag expected, '<' not found in must_have_modules_list.xml file\nError found: Start tag expected, '<' not found in modules_native_addons.xml file\nError found: Start tag expected, '<' not found in default_country_modules_list.xml file<\/code><\/pre><\/div>Note<\/div>These errors appear in PrestaShop 1.7 and PrestaShop 8.x. In older versions 1.6, the mechanism works similarly, although the location of some files may differ.<\/div><\/div>
Where does this error come from?<\/h6>PrestaShop sends HTTP requests to the PrestaShop Addons API to retrieve current module listings. An example endpoint looks like this:
https:\/\/api.addons.prestashop.com\/?version=1.7.8.x&method=listing&action=must-have<\/code><\/pre><\/div>The store expects a response in XML format. The problem arises when:- API Addons returns a response in a different format (e.g., JSON or an HTML error page).<\/li>
- Connection to the API is blocked by a firewall or server configuration<\/li>
- The shop server does not have access to external resources (no outgoing HTTP\/HTTPS traffic).<\/li>
- API Addons is temporarily unavailable or returning a timeout.<\/li>
- The PrestaShop version is too old and is no longer supported by the API<\/li><\/ul>PHP Parser simplexml_load_string()<\/span> when trying to process an incorrect response, it reports this exact error \u2013 Start tag expected<\/em>.
Does the error affect the store's operation?<\/h6>Success<\/div>The frontend of the store, shopping cart, orders, payments, and all purchasing processes are working normally. The error only concerns the admin panel \u2013 specifically the module management section.<\/div><\/div>What could stop working in the panel:- list of recommended modules<\/li>
- \u201eMust-have\u201d section in the module manager<\/li>
- marketplace Addons accessible from the admin panel<\/li>
- Module suggestions for the country<\/li>
- Slower page loading Modules (timeout when trying to connect to the API)<\/li><\/ul>
Step 1 \u2013 Checking the XML file contents<\/h6>Before making any changes, it's worth checking what is currently in the files. By SSH<\/a> we perform
cat config\/xml\/must_have_modules_list.xml<\/code><\/pre><\/div>If the file is empty, contains HTML (e.g., a 503 error page) or JSON instead of XML, that is the source of the problem.
Tip<\/div>You can also use the file manager in the hosting panel (e.g., Hestia CP, cPanel) or an FTP client to check the file contents \u2013 SSH access is not required.<\/div><\/div>
Step 2 \u2013 replacing files with the correct XML<\/h6>The fastest solution is to replace the content of the problematic files with minimal, correct XML. Via SSH, we execute:
echo '' > config\/xml\/must_have_modules_list.xml\necho '' > config\/xml\/modules_native_addons.xml\necho '' > config\/xml\/default_country_modules_list.xml\necho '' > config\/xml\/trusted_modules_list.xml<\/code><\/pre><\/div>You can also upload files manually via FTP. The content of each file should look like this:
<\/code><\/pre><\/div>Warning<\/div>Simply replacing the files will only temporarily solve the problem. PrestaShop will try to fetch data from the API again the next time the modules page is refreshed and might overwrite the files with an erroneous response.<\/div><\/div>
Step 3 \u2013 Permanent Solution via Class Override<\/h6>To permanently block XML download attempts from the Addons API, we are creating a class override Tools<\/span>. We are creating a file:
override\/classes\/Tools.php<\/code><\/pre><\/div>Regarding the following content:
<?php\nclass Tools extends ToolsCore\n{\n protected static $is_addons_up = false;\n}<\/code><\/pre><\/div>Property $is_addons_up = false<\/span> causes PrestaShop not to attempt to connect to the Addons API \u2013 and consequently, it will not download or overwrite XML files.
After creating the override file, we clear the cache. For PrestaShop 1.7 \/ 8.x<\/strong>:
rm -rf var\/cache\/dev\/*\nrm -rf var\/cache\/prod\/*<\/code><\/pre><\/div>You can also clear the cache from the administration panel: Advanced > Performance > Clear cache<\/strong>.
Info<\/div>After applying the override, the modules section still works fully \u2013 you can install, uninstall, and update modules from a ZIP file. Only the integration with the Addons marketplace in the admin panel is disabled.<\/div><\/div>
Alternative \u2013 blocking file writes<\/h6>If we don't want to use overrides, XML files can be set to read-only. PrestaShop won't be able to overwrite them:
chmod 444 config\/xml\/must_have_modules_list.xml\nchmod 444 config\/xml\/modules_native_addons.xml\nchmod 444 config\/xml\/default_country_modules_list.xml\nchmod 444 config\/xml\/trusted_modules_list.xml<\/code><\/pre><\/div>Note<\/div>The chmod method is simpler, but it doesn't eliminate API connection attempts - PrestaShop will still perform them, which can slow down module page loading. Overriding the Tools class is a technically cleaner solution.<\/div><\/div>
What don't we lose after disabling the Addons API?<\/h6>It's worth knowing that in a production environment, most of these features are not used on a daily basis anyway: