Thanks to 2,870 Crowdin contributors, PrestaShop has been translated in over 65 languages, helping merchants to create shops in over 200 countries! Translating PrestaShop allows us to aim at millions of potential users and merchants from all around the world. We’re very proud of the work done and hope to bring e-commerce to a growing number of people, no matter what their country or language is. In order to keep reaching new people, we are today releasing our translator guide, so that anyone can start contributing to the translation project!

Why a translator’s guide?

We’ve created this guide to provide translators with useful information and references on our translation project on Crowdin. Whether you’re a merchant, a developer, a beginner or a more experienced translator, we hope you’ll find it helpful and that it will achieve its main promise: to guide you in making a good-quality translation job.

Thanks to a detailed description of the translation process, its fundamentals, and its best practices, we hope to:

• Make it easy for anyone to start translating PrestaShop right now using the Crowdin platform.
• Allow every user to anticipate the most widespread mistakes or difficulties they might come across while translating or using Crowdin.

How was it built?

We wanted this guide to be clear and straight to the point with visual indicators (graphs, tables, screenshots, table of contents, warnings, etc.) for the users to find the required information easily. It describes the steps to join our Crowdin project page, contains an overview of Crowdin’s translation area, some useful workarounds (such as how to find context for the strings to translate, how to handle variables and tags, etc.), as well as translation best practices. We’ve also added a FAQ to answer the major hurdles you might have to face.

You can download the Translator’s guide here:

Download the PDF guide

If you want to contribute in any other way to PrestaShop (for code, documentation, support, or bug reporting), check our How to contribute guide.

In order to improve this guide and be more helpful for the community, we need your feedback. Feel free to share your opinions with us!

Thank you!

PrestaShop 1.6.1.6 is now available. This maintenance release has seen 20 changes since version 1.6.1.5 (released on April 13th).

Yes indeed, we have been mentionning v1.6.1.6 since May but, y’know, with the lifting work necessary to get PrestaShop 1.7 Beta 1 off the ground, the 1.6.1.6 release had to be delayed a bit. Here it is at last!

As the version number indicates (as per our SemVer-like versioning), this is the 6th patch release for PrestaShop 1.6.1.0.

As usual, if you are currently running promotions leading to high traffic on your website, we recommend that you wait for the promotion to end before attempting any upgrade and technical change to your store.

We hope you enjoy this new patch release!

The changes

For a full list of changes, see the list of pull requests merged into the 1.6.1.x branch in this milestone

Here are some of the most notable changes that this version brings:

• FO: Cart Rules have an improved customer display, with much more useful information.
• BO: All carriers are now displayed in the Dashboard.
• Core: Fixed “Uncaught exception ‘PrestaShopException’ with message ‘Property StockAvailable->id_product_attribute is empty”.
• WS: Compatibility fox for PHP 5.2, 5.3 and 7.0.
• PDF: Pagination is now implemented for all PDF types.
• Tests: Fix for PHP7.
• Several smaller fixes.

The PrestaShop 1.6.1.6 changelog is available.

Since version 1.6.1.6 is a “patch” update to version 1.6.1.0, upgrading from that version will be as smooth as silk for everyone: features will work better, and modules & themes which worked fine on 1.6.1.0 will work just as well with 1.6.1.6.

This release had 13 contributors, both from PrestaShop and from the Community at large.

• @alexsegura
• @firstred
• @hiousi
• @idnovate
• @julienbourdeau
• @kelu95
• @maximebiloe
• @mickaelandrieu
• @nobodaddy
• @okom3pm
• @raphael-homann
• @rgaillard
• @xbordere

A huge “thank you!” to each of the 7 outside contributors, who gave their time and knowledge for the benefit of the whole PrestaShop community! You too can contribute to the next version!

Let’s go, upgrade your store(s)! Upgrading from 1.6.1.0-1.6.1.5 is completely safe, upgrades from a standard 1.6.0.x version should work just as well, and those upgrading from version 1.5, 1.4 or even 1.3 should take their time and pay attention to their modules, their theme and their custom modifications!

Download 1.6.1.6 now!

Existing modules should mostly work as-is with version 1.7. In this article, we dive into that “mostly”!

As you certainly know, all well-written 1.6 modules should work with little to no changes in version 1.7, except:

• Those which target the theme/front office – because we rewrote the way themes are written.
• Those which target the Product page – because the DOM of this page has changed.
• Those which target the Modules page – again, because the DOM of this page has changed.

What this means for any upgrade is that in order for a PS 1.6 to migrate to PS 1.7, you (or your agency) will have to:

• Rewrite the theme, ideally using the Starter Theme or the default theme.
• Adapt the Product page modules (CSS and JavaScript).
• Adapt the Modules page modules (CSS and JavaScript).
• Test all the other modules – as you would for any new release.

In any case, we advise you to make sure that your module does work in PrestaShop 1.7.

(the information above comes straight from the PrestaShop 1.7 Project FAQ. Read it if you haven’t yet!)

Now, let’s dive into the details.

General information

• We changed all variables passed to Smarty: make sure what you use is still assigned!
• Objects are no longer passed to Smarty. We only use arrays now.
• Smarty’s strings are now automatically escaped:
• You should remove all your |escape:'html':'UTF-8' (FOR FRONT OFFICE TEMPLATES ONLY).
• You should add the nofilter tag if you print HTML.
• $link is deprecated. Use the {url} helper instead.
  • Even if $link is still passed to Smarty, it will be removed at some point in a future version.
• Make sure you use the new way of calling templates: fetch(module:modulename/views/template.tpl).
• Make sure you do not add your assets with a hardcoded path in the displayHeader hook.
  • Nothing new from v1.6 here, but it’s a bad practice.
• Only rely on documented variables!

Overrides and namespaces

PrestaShop 1.7 introduces the use of namespaces with its new architecture, and in short, anything that has namespaces cannot be overridden.
The legacy architecture can still be overridden, though. But in general, we advise against overriding code. It is better to extend it.
Also, overrides are currently forbidden in the Symfony-based pages (namely, the Product page and the Modules page).

Overrides are a nice system to have, but the issue with it is that it is an uncontrolled extension system. We are working on a carefully planned process that will allow developers to extend the PrestaShop code in a much cleaner way. The gist of it would be that the developer team would integrate your needs for overrides in the next version of PrestaShop – kind of what polyfills do for HTML5 features :) In short, you tell us what you need, and while we include it in the next version, you can use an override.

Again: the override system is not going away, you will still be able to easily extend PrestaShop. We’re just changing the way we want this to happen: instead of each developer having a separate set of overrides, we want developers who need an override to let us know about it, so that the next version of PrestaShop includes it directly.

Introducing the PrestaShop UI Kit

The Product page and the Modules page are the only two pages that have been rewritten using Symfony, and they still work fine with pre-1.7 modules – albeit with a necessary design adaptation, as happened in all major version of PrestaShop before, only this time we provide a UI Kit to help developers easily have a consistent style for their module screens.

The whole PrestaShop 1.7 back office has its design based on the UI Kit. This UI Kit was built so that designers and developers can create interfaces which are consistent in style with the administration interface.

Check its reference documentation here: http://build.prestashop.com/prestashop-ui-kit/
Check its code here: https://github.com/PrestaShop/prestashop-ui-kit

Note that it is still a work in progress, and should not be considered stable until 1.7 is released.

Payment API change

Payment modules should be particularly looked after, as we wrote in the third article about the Starter Theme.

To provide the best user experience possible for customers, and to guarantee that PrestaShop orders respect the law in all countries, we slightly changed the payment API.
For example, the Terms & Conditions checkbox is now displayed with the payment options, and there is only one button to click in order to pay.
That way, theme designers have more control of the layout of payment options.

Hook changes

The updated payment API changes the parameters passed to these two hooks:

• hookPaymentReturn
• hookDisplayOrderConfirmation

Before

After

Sample code

Everything can be retrieved from order. For instance.

$currency = new Currency($params['order']->id_currency);
$total_to_pay = $params['order']->getOrdersTotalPaid();

We advise you to dive into the Payment Example sample module, or to explore the native Bankwire module– most notably the commit that updated this module for 1.7.

Changes for modules targeting the Product page

The Product page has been entirely rewritten for PrestaShop 1.7 in order to make the product creation easier, faster, and more logical. 6 default tabs instead of the previous 12, with the main tab containing much more information; a greatly improved Combination generator/manager; new shortcuts; an in-page catalog browser; and other niceties…

If you created modules which target the Product Page, you may be impacted by these changes. To make them work as expected in the new Product page, you will need to adapt your code.

Here are the main information that you will need to update your modules.

Handling tabs

In PrestaShop 1.6, it is allowed to have a dedicated tab per module on the Product page. In version 1.7, we changed this and added a dedicated tab for all the Product page’s modules, via a new hook called hookDisplayAdminProductsExtra.

If you coded your modules by following the best practices of both PHP and PrestaShop 1.5-1.6, it should not take you too much time to update your code.

Back office hook Parameters

Parameters cannot be obtained from a query string anymore. From now on, an array of parameters is directly passed onto the hookDisplayAdminProductsExtra method.

See this sample hook:

public function hookDisplayAdminProductsExtra($params)

With $params taking these values:

$params [
  "_ps_version",
  "id_product",
  "cookie",
  "cart",
  "altern"
]

Assets

The URLs of back office assets (CSS, JavaScript, images, etc.) must be absolute, meaning that they must start with http:// or https://.

You can use the Tools::getCurrentUrlProtocolPrefix() method to make sure you always use the correct protocol.

Form fields

The form field names must be created in an array hook of this format: [MODULE_NAME][INPUT_NAME].

DOM

The format of the ID for the module’s container has been modified. Here is its new format: module_MODULE_NAME.

Changes for modules targeting the default theme.

All the 1.6 modules targeting the theme will likely be impacted (to various degrees) by the changes and need to be adapted for 1.7. From the moment your module targets the theme, it will have to be updated.

The Theme documentation

The Designer Guide is currently being entirely rewritten to focus on the 1.7 Theme system. We expect it to be available online in the coming weeks.

In the meantime, we invite you to dive into the source code:

• The Starter Theme, which you can use as a skeleton template for your 1.7 theme:
  https://github.com/PrestaShop/StarterTheme/tree/master
• The 1.7 default theme, called “Classic”, which can you can learn from:
  https://github.com/PrestaShop/PrestaShop/tree/develop/themes/classic

Widgets

PrestaShop 1.7 introduces widgets, which you can use to place your module’s content directly in your theme.

Widgets introduce 2 major features for theme developer:

• You can use a module directly within a theme.
• Widgets can be hooked to any display hook.

More information about this will be available in the soon-to-be-available PrestaShop 1.7 Designer Guide.

Hook changes

The front office hooks have seen a bit of evolution. Some have been moved, some have been removed, and some have been created. Here are the lists!

1.6 hooks that are not available in 1.7

These hooks were only available in 1.6. They are removed from 1.7.

Hooks that were added in 1.7

These hooks are only available in 1.7.

Location changes

These hooks are common to PrestaShop 1.6 and 1.7, but their file location has changed in 1.7.

That’s it for now!

More information is coming soon!

If you have specific questions about module development that are not answered in this article, let us know in the comments: it will help us build a better Developer Guide!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous three weeks, from Monday 23rd of May to Sunday 12th of June 2016.

Milestones

We released PrestaShop 1.7 Beta 1!
We also released PrestaShop 1.6.1.6!
We published an article about the module development changes in PrestasShop 1.7!
We also published the PrestaShop Translator Guide AND the PrestaShop Contributor Guide!
We even told how the new default theme was designed!
The days are just PACKED! :)

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 Theme Development doc (yes, it is very sparse at the moment).

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Do you live near Paris? Do you want to come test-drive the design of PS 1.7? Let us know!

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Text changes

• 3840: Update wording invoice.tax-tab.tpl. Thank you @nobodaddy!
• 4921: “Manufacturer” becomes “Brand”, by @alexeven.
• 5610: Update tabs name about modules in the back office menu, by @maximebiloe.
• 5652: product page - wording updates, part 1, by @alexeven.
• 5684: Misspelling correction of filemanager return. Thank you @pirkoa!
• 5685: Fix a typo in the filemanager. Thank you @crugnac!
• 5686: Misspelling correction. Thank you @crugnac!
• 5689: Wording update of the product page, by @alexeven.

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 6909: Allow bots to crawl module images. Thank you @gskema!
• 5427: Fix alignment in order history. Thank you @shepherdv8!
• 5514: Fix duplicate IDs in Link List module. Thank you @fojtcz!
• 5550: Reorganize subtotals for cart, checkout summary and order summary, by @julienbourdeau.
• 5598: Display unit price in detailed cart product list, by @julienbourdeau.
• 5608: Prevent a guest customer to access to auth required pages, by @maximebiloe.
• 5621: Improve performances, by @jocel1.
• 5622: Uniformize labels for price, discounts, unit prices for product page, by @julienbourdeau.
• 5624: Fix undefined var on maintenance tpl, by @Quetzacoalt91.
• 5625: Fix blockreassurance and promo code layout, by @maximebiloe.
• 5630: Fix an undefined index on cart and order confirmation layout, by @maximebiloe.
• 5631: Checkout: Always display customer for guest, by @julienbourdeau.
• 5638: Fix cart summary display when selecting another carrier, by @julienbourdeau.
• 5641: Display correct tab content for product page on dom update, by @julienbourdeau.
• 5644: Display customized products as distinct products in shopping cart, by @maximebiloe.
• 5657: Improve customization display in order confirmation email. Thank you unlocomqx!
• 5659: Fix prices layout in add to cart modal, by @maximebiloe.
• 5661: Fixes taxes labels for front, by @julienbourdeau.
• 5662: Fix content loaded in the modal when several links, by @julienbourdeau.
• 5667: Update product page elements when click on continue shopping, by @mickaelandrieu.
• 5668: Add a new hook on cart product line, by @maximebiloe.
• 5669: Do not allow to pass configuration values even with _PS_MODE_DEV_, by @rgaillard.
• 5677: Fix bugs on thumbnails of product page, by @maximebiloe.
• 5693: Fix undefined variable in Order detail. Thank you @fojtcz!
• 5699: Refactor order confirmation controller, by @julienbourdeau.
• 5702: Use a textarea for conditions not a CMS page anymore, by @maximebiloe.
• 5707: Add domain to translatable strings in Classic template files, by @julienbourdeau.
• 5708: Fix birthdate placeholder format inconsistency. Thank you @unlocomqx!
• 5713: Add domains for all front controllers, by @julienbourdeau.
• 5717: Add domains to all FO strings in src, by @julienbourdeau.

Back office

• 4446: Allow basic HTML attributes in editor. Thank you @mcdado!
• 5283: Added “Sort by access date” on module page, by @tchauviere.
• 5549: Introduced bulk edition on combinations, by @mickaelandrieu.
• 5573: Introduced a default section for deprecated modules, by @mickaelandrieu.
• 5584: Improved HelperOptions for textarea field. Thank you @kpodemski!
• 5589: Fixed HTML errors on Product Page, by @mickaelandrieu.
• 5605: Display attributes list in combinations tab of the product page, by @maximebiloe.
• 5607: Redirect to new module controller, by @julienbourdeau.
• 5611: Improve new header integration, by @nihco2.
• 5612: Easier way to go to Maintenance page while shop is turned off. Thank you @kpodemski!
• 5616: Fix combinations generation when using attributes list, by @maximebiloe.
• 5618: Improve combinations list layout according to mockups, by @maximebiloe.
• 5619: Fix unecessary AJAX call to notifications, by @maximebiloe.
• 5623: Fix undefined JS on modules catalog, by @maximebiloe.
• 5629: Compile all Webpack files, by @shudrum.
• 5633: revert product update, by @mickaelandrieu.
• 5634: fixed product deletion from catalog, by @mickaelandrieu.
• 5635: Fix redirect issue when accessing to index.php in Ajax, by @maximebiloe.
• 5637: Improve read more modal integration, by @nihco2.
• 5639: Fix delete alert when switching from a combination to another, by @maximebiloe.
• 5645: Made the final price dynamic according to impact on price in BO, by @mickaelandrieu.
• 5647: Redirect old adminproducts url to new controller, by @julienbourdeau.
• 5650: Fix product default category selection on Firefox, by @maximebiloe.
• 5653: Display the public name and in the good language for attribute groups, by @maximebiloe.
• 5660: Improve bulk actions design, by @nihco2.
• 5663: Change ajax login URL to use Symfony functionnalities, by @quetzacoalt91.
• 5665: Synchronized final price when we bulk edit the impact on price, by @mickaelandrieu.
• 5673: Fix error on module actions, by @quetzacoalt91.
• 5674: On new product category creation, create also the label in tree, by @mickaelandrieu.
• 5678: Change sort by scoring order to desc in module list. Thank you @antho-girard!
• 5688: Fix BO product search & autocompletion, by @quetzacoalt91.
• 5709: Fix a smarty warning when opening the Carrier Wizard. Thank you @prestamodule!
• 5720: Update some strings with html tags inside to make them easier to translate, by @maximebiloe.
• 5721: Fixed bug while detect mcrypt lib in AdminPerformanceController. Thank you @alexdee2007!
• 5725: Improved the product combinations bulk form, by @mickaelandrieu.

Core

• 5037: Add return in Attribute::cleanPositions. Thank you @pifyz!
• 5151: Remove unused parameter “$specific_where” in “ObjectModelCore::updateMultishopTable”. Thank you @pifyz!
• 5241: Fix fatal error on classes/stock/StockAvailable.php, by @xborderie.
• 5406: Update TCPDF to version 6.2.12. Thank you @firstred!
• 5512: Remove unnecessary ternary operator. Thank you @shagshag!
• 5557: Fixed bug for a clear cache, by @shine-neko.
• 5577: Make id_product available in checkout confirmation e-mail, by @paddl.
• 5579: Optimized Cart class, by @mickaelandrieu.
• 5580: improve global performances, by @jocel1.
• 5620: Minor fixes on composer and translations, by @quetzacoalt91.
• 5627: Allow uppercase extensions to be uploaded. Thank you @unlocomqx!
• 5628: Remove duplicate VENDOR_DIR constant. Thank you @panploenes!
• 5642: Cache result Cart::getTotalShippingCost() according to parameters, by @julienbourdeau.
• 5646: Get module errors on failure and fix upload popup, by @quetzacoalt91.
• 5649: Add documentation to resize function params. Thank you @e-gaulue!
• 5651: Do not write parameters.yml in bootstrap.php and other minor fixes, by @quetzacoalt91.
• 5654: Bypass zip format if no format required, by @julienbourdeau.
• 5656: Fixed the attribute group deletion, by @mickaelandrieu.
• 5666: Travis - Move APT commands in addons, add cache and use another version of MySQL, by @quetzacoalt91.
• 5675: Take into account the unit price impact set by combination, by @maximebiloe.
• 5676: Cleanup smarty configuration files, by @julienbourdeau.
• 5679: Synchronize Classic, Core and StarterTheme to make it testable, by @maximebiloe.
• 5711: Introduce Symfony translation, by @jtabet.
• 5712: Fixed bad behavior on category creation from Product page, by @mickaelandrieu.

Installer

• 5600: Prevents access to the database if you have not installed shop, by @shine-neko.
• 5613: Fix composer install with no-dev option, by @quetzacoalt91.
• 5632: avoid fetch() on null query result, by @mickaelandrieu.
• 5636: Production & development cache conflicts fixed, by @shudrum.
• 5655: Installer cache generation fixed, by @shudrum.
• 5716: Replace bad check of PDO extension, by @rgaillard.

Tests

• 5696: Composer requires friendsofphp/php-cs-fixer, by @quetzacoalt91.

Webservice

• 5265: Translate supplier order states. Thank you @firstred!

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @alexdee2007, @antho-girard, @crugnac, @e-gaulue, @firstred, @fojtcz, @gskema, @kpodemski, @mcdado, @nobodaddy, @panploenes, @pirkoa, @prestamodule, @shagshag, @shepherdv8, and @unlocomqx! Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

Here is the latest report to inform you of what has been going on PrestaShop translation project on Crowdin lately (= this last May).

Project news

Updated 1.6 translations

We’ve again updated the translations available in PrestaShop this week, so that you can find the latest translation available in PrestaShop. That should be of importance for the Turks, as a lot of proofreading has been going on lately.

From now on, we plan on updating the 1.6 translations every two weeks, so next time should be around the end of June. No promises however!

Translations for PrestaShop 1.7

You’ve probably heard we’ve released the first beta version for PrestaShop 1.7. We’d like to open the translation for PrestaShop 1.7 soon, so that the work can start on these shiny brand new strings! We’re working on a whole new translation system, to make things easier for translators. We’ll tell you more about it soon here on Build. This is not ready yet, but it’s keeping us busy :) We hope you’ll like it!

Translator’s Guide

We’ve also published a new Translator’s Guide to help you getting familiar with PrestaShop translation project. If you haven’t done it yet, get it now! We’d be happy to hear from you, if you think we should add some content or answer more of your concerns.

Get the Translator Guide

Now let’s get back to our Crowdin project, and the full report of its activity in May:

A few stats

• 89 contributors joined the project this month, for a total of 2,846 members at the end of May. Welcome to them!
• 34 members were active on the project this month.
• A total of 17,950 words have been translated and 9,956 validated.
• All this in 22 different languages.

Thank you for your involvement!

Top contributors

A lot of you are working everyday on Crowdin to have PrestaShop available in many languages, and we can’t thank you enough for your dedication! Here are the most active translators and proofreaders this May.

Top 10 translators in May:

Top 10 proofreaders in May:

A big applause to them! And welcome to our new top contributors!

Complete translations

Fully translated languages

At the end of May, PrestaShop 1.6.1 was fully available (= 100% translated and validated) in 16 languages:

• Bulgarian
• Croatian
• Dutch
• English
• French
• Indonesian
• Italian
• Lithuanian
• Norwegian
• Persian
• Polish
• Russian
• Slovak
• Slovenian
• Spanish
• Swedish

98-99% translated languages

PrestaShop was also almost fully translated (and/or validated) in these 6 languages:

• Czech
• German
• Portuguese
• Portuguese, Brazilian
• Romanian
• Vietnamese

A little bit of work and these languages can be 100% translated and validated too! If you feel like you want to help, join the project!

Languages with the best evolution

In comparison with March 2016, the following languages had the best progress in May:

• German, Luxembourg (+500% to reach 6% translated - wow!)
• Basque (+5% to reach 21% translated)
• Turkish (+4.2% to reach 100% translated - hurrah!)
• Chinese, Traditional (+2.7% to reach 77% translated)
• Spanish, Colombia (+1.3% to reach 78% translated)

Of course this is highlighting the languages that made some progress with new translations; but it doesn’t mean that the languages that aren’t mentionned here aren’t active. Indeed, some editing and rewriting could be going on, but the % of translation wouldn’t be modified (since it’s working on strings that are already translated). So let’s not forget about the work of these proofreaders! Thank you too!

Languages that need (more) proofreaders

A translated string will not be available in PrestaShop as long as it is not validated. For this reason, it’s important we should keep a good level of validated strings vs. translated strings, to make sure everyone benefits from the latest translations!

At the end of May, 7 languages would highly benefit from more proofreading:

• Turkish (100% translated vs 2% validated)
• Greek (100% translated vs 81% validated)
• Romanian (100% vs 84%)
• Ukrainian (100% vs 53%)
• Hungarian (92% vs 72%)
• Arabic (54% vs 28%)
• Galician (49% vs 11%)

N.B.: Since the end of May the Turkish project has been moving forward, and a lot of proofreading is going on. As I’m writing, Turkish is already 29% validated, which is great! Keep up the good work! :)

If you wish to help proofreading what has been translated, please contact me on Crowdin with the language you’d like to proofread. We need your help!

If you haven’t joined us on Crowdin yet, it’s never too late!

If you want to gather your fellow translators to work towards a better harmonization, start a glossary, or anything else, do let us know: we’ll include a word about it in the next monthly report.

Do you have a question, a remark? Don’t hesitate to leave a comment. See you next month!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 13th to Sunday 19th of June 2016.

General messages

Have you tested Beta 1 of PrestaShop 1.7?
Have you tried one of your module in 1.7? Have you tried to create a 1.7 theme? How did it go?
Give us your feedback!

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Do you live near Paris? Do you want to come test-drive the design of PS 1.7? Let us know!

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Text changes

• 5728: Update NL country names in installer. Thank you @firstred!
• 5729: Update NL menu tabs. Thank you @firstred!

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5274: Use per shop product visibiliy. Thank you @venditdevs!
• 5606: Enable download of larger files. Thank you @jguix!
• 5727: Localize date format in customer registration form. Thank you @unlocomqx!
• 5736: Add translation domains for front controllers, by @alexeven.
• 5741: Add selected_delivery_option in payment step, by @julienbourdeau.
• 5743: Update address form when changing country, by @maximebiloe.
• 5753: Added domain for module overrides in Classic, by @julienbourdeau.
• 5756: Optional final checkout summary before payment, by @paeddl.
• 5763: Handle RTL in Classic, by @maximebiloe.

Back office

• 5251: Sort attribute combination in Product admin page, by @cocoweb94.
• 5460: Allow slash character in phone numbers. Thank you @gwarnants!
• 5626: Add new hook to add order actions in Back Office, on an order view. Thank you @prestamodule!
• 5732: Fixed uncaught type error, by @mickaelandrieu.
• 5734: Synced final product price in pricing with combinations, by @mickaelandrieu.
• 5735: Fix unexpected loading on modules page, by @mickaelandrieu.
• 5737: Fix display of the listing filters on the toolbar, by @rgaillard.
• 5742: Do not limit div height for module failure details, by @quetzacoalt91.
• 5748: Synced prices between basics and combinations tabs, by @mickaelandrieu..
• 5750: Add translation domains for modules messages, by @alexeven.
• 5754: Add translations on module manager & module page, by @quetzacoalt91.

Core

• 5348: Added filter_key and havingFilter to array date_add. Thank you @studiokiwik!
• 5412: Fix warning when duplicating products. Thank you @mcdado!
• 5414: Added template name in error when no template found for module. Thank you @prestamodule!
• 5692: Fix error log path. Thank ou @fojtcz!
• 5695: Remove a method introduce in PrestaShop 1.5 dev but not used. Thank you @prestamodule!
• 5715: Enable Doctrine cache in prod, avoid extra memcached calls, by @jocel1.
• 5722: Remove PrestaShop Translator Adapter and use Symfony default one, by @julienbourdeau.
• 5740: Introduce Symfony translator getter for modules, by @alexeven.
• 5745: Do not set the dump function if it exists, by @shine-neko.
• 5751: Clean translations domains, by @shine-neko.
• 5761: Fix comments and whitespace. Thank you @mcdado!

Installer

• 5714: Avoid error on install first step if app/log is not writable, by @rgaillard.

Tests

• 5733: Set absolute path instead of relative for tests, by @quetzacoalt91.
• 5747: Travis: Test Twig and Yaml file syntax, by @julienbourdeau.
• 5767: Small improvements for Selenium tests. Thank you @kpodemski!

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @fojtcz, @gwarnants, @jguix, @kpodemski, @mcdado, @prestamodule, @studiokiwik, @unlocomqx, and @venditdevs! Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 20th to Sunday 26th of June 2016.

General messages

More than a year after creating the 1.6.1.x branch (and thus, deprecating the 1.6 branch) and warning not to use the 1.6 branch anymore, we chose to finally close the 1.6 branch. Several pull requests (79, to be exact) remained open in the old 1.6 branch, most of which could not be merged anymore for obvious reasons; they were automatically closed as soon as we closed the branch.
Despite our “Review your PR” campaign in November 2015, which asked PR contributors to update their code and switch it to the 1.6.1.x branch or the develop branch, many PR remained untouched. While we did port some to the develop branch, we just cannot work them all into PS 1.7 while we are hard at work making it happen.

About 1.7…

Have you tested Beta 1 of PrestaShop 1.7?
Have you tried one of your module in 1.7? Have you tried to create a 1.7 theme? How did it go?
Give us your feedback!

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Do you live near Paris? Do you want to come test-drive the design of PS 1.7? Let us know!

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Text changes

• 4485: Update country translations in Swedish. Thank you @macroy!

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5769: Fix class typo in Payment step. Thank you @fojtcz!
• 5770: Remove spaces from textarea in Contact form. Thank you @fojtcz!
• 5772: Tax entry should be displayed before totals, by @mickaelandrieu.
• 5777: Made the Symfony error/exception handler availables in front office, by @mickaelandrieu.
• 5779: Handle cart with virtual products, by @maximebiloe.
• 5782: Adds title tag to banner link. Thank you @dh42!
• 5783: Fix undefined variable on order confirmation, by @maximebiloe.
• 5787: Removing logo text from logo. Thank you @dh42!
• 5788: Increases social share button blick pad. Thank you @dh42!

Back office

• 5385: Category name can now be a single character. Thank you @antho-girard!
• 5390: Changed right management system to something closer to SF2’s security, by @jtabet.
• 5583: The maintenance text can be customized from the back-office. Thank you @kpodemski!
• 5760: Add Not Null check on module upload, by @quetzacoalt91.
• 5764: Enable justify option in TinyMCE, by @maximebiloe.
• 5765: put legacy context on cache during a request, by @mickaelandrieu.
• 5773: Add missing translation domains for ModuleController, by @alexeven.
• 5784: Domains added to the product page, by @alexeven.
• 5785: Add translation domains, by @alexeven.

Core

• 5316: Fixed deprecation on YAML component, by @shine-neko.
• 5510: Clean-up code on clearCache() function. Thank you @zizuu-store!
• 5731: Deflate .svg files. Thank you @mrmanchot!
• 5758: Adapt payment api for Atos payment option, by @maximebiloe.
• 5771: Custom translations, by @jtabet.
• 5775: Rename ESlint config file according to new recommendation, by @julienbourdeau.
• 5776: Use already defined tax variable instead of recalculate it, by @maximebiloe.
• 5780: Set unit_price for product lists, by @maximebiloe.
• 5781: Fix theme deletion, by @maximebiloe.

Installer

• 5757: Added SF translation download & unzip during installation, by @jtabet.
• 5762: Add translation domains in install, by @shine-neko.
• 5768: Ability to add a theme during installation, by @shine-neko.
• 5778: Convert script update-eu-taxrulegroups.php in symfony Command, by @shine-neko.

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @antho-girard, @dh42, @fojtcz, @kpodemski, @macroy, @mrmanchot, and @zizuu-store! Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

Our core team worked closely in the past few months with the Microsoft Azure Team to build 4 ready-to-use PrestaShop cloud hosting plans. You’re invited to discover an exclusive preview of it in Paris next week!

From standalone virtual machines to multi-VMs solutions, these 4 offers have been built to help you be more adaptable and scalable. They include powerful tools and services, such as high availability, SQL clusters and load balancers with auto-scaling web servers just to name a few.

Come to our PrestaShop + Azure event next week in Paris: the 7th of July, meet the teams in charge of the project at PrestaShop and Microsoft, and find out more information about it:

• How these hosting solutions were created
• Why we built 4 different architectures
• How to use them
• How you can benefit from it

Our guest speakers will be:

• Hervé Leclerc, CTO @ Alterway, Microsoft Azure historical partner
• Jean-François Gomez, Business Development Manager @ Microsoft Azure
• Thomas Conté, Cloud Architect @ Microsoft Azure

Register to the event

This event will be technical and is mainly targeting developers, CTOs, web agencies and sysadmins. If you can physically attend the event in Paris on Thursday 7th July, please subscribe on Eventbrite (in French).

Where: PrestaShop HQ, 12 rue d’Amsterdam, 75009 Paris, France
When: Thursday 7th July from 18:00 to 21:00.
What: PrestaShop + Azure, but also pizzas - and you’re welcome to stay watch the UEFA 2016 semi-final with us (we have beer too!).

If you can’t make it, we’ll be broadcasting the event online and you’ll be able to follow it by registering here.

See you there!

Please note that this event will be in French, as is it our first one on this topic. If you wish to see an English webinar, please contact me at guillaume.bruere@prestashop.com and I’ll organize it!

With the introduction of Symfony in PrestaShop 1.7, we had to rethink how our system of translation worked, to make sure new pages were translatable too. Instead of merely adapting our current system to Symfony, we took this opportunity to rethink how it works, to optimize it a bit.

This is still a work-in-progress project, and even if we plan on opening 1.7 to translation on Crowdin soon, it doesn’t mean the 1.7 version is ready to support translations yet. We’ll keep you updated as the project moves forward.

In short:

• We’re introducing a new translation system to be compatible with Symfony
• There are new standards on how to write strings
• Using translations domains, that are organized functionally
• So words like “Save” will be translated only once across the whole project
• And the Crowdin project will have more folders and smaller files for 1.7 version

Why we needed a new system

The big WHY is that we had to adapt our former in-house translation system to Symfony, to technically support translations in PrestaShop 1.7. From there, it seemed to be a good occasion to improve how the translation system works in Crowdin too.

For those of you who are familiar with the Crowdin translation project, its organization is not that optimal. Among its flaws, users have unanimously elected the following ones as most annoying:

• Lack of context: The only context given was the name of the source file - if you knew where to find the information.
• Duplicated strings: Strings with many occurrences like “Save”, “Products”, “Order” had to be translated several (many) times, because they came from different files, and therefore different “contexts”.
• Massive, endless files: Everything that was related to admin (or theme, for that matter) was gathered inside one big file.

All this has one main cause: both context and project organization rely on the source file from where the string comes from.

For instance, most of the content from the back office is gathered in the “Admin” folder, but each string is given a different context, based on the exact file from which it was extracted. Which gave something like:

(And a lot of duplicated strings)

We also have 46% of the whole translatable strings in one file, split down in 104 pages in Crowdin. You need much courage if you want to translate the PrestaShop 1.6 back office (and many of you didn’t stop at this, thanks a lot for your dedication!!).

So, we came up with what we hope is a better translation system, which:

• Avoids duplications - no need to translate 10 times “Edit” or “Add to Cart”
• Provides richer context with
  • Comments from the source file
  • Line number from the source file
• Is better organized in Crowdin
  • More folders to provide a global context
  • Smaller files to make it easier to see one’s progress
  • Folder organization to help prioritize (translate feature-related content in priority, help text later for instance)

It’s mostly based on domains.

What is a domain and how to code strings?

PrestaShop 1.7 having introduced the use of Symfony framework, we’re adapting the translation system to follow the Symfony way. Domains will give the functional context for a string, as explained below.

What’s changing from now on

• Any string should call Symfony’s translator.
• We’re adding a compulsory array() parameter for variables, whether there are variables in the string or not. It should be here in all cases, in .php files.
• Variables should be named clearly after what they depict (i.e.%productname%), and no longer be a mere %s or %1$s.
• All strings should have a domain, for instance ‘Shop.Notifications.Error’.

The translation files structure and format in PrestaShop will also change:

• There will be folders, matching the domain architecture.
• Files will be in .xlf format, instead of .php. They will contain the source strings too (a big big improvement!).
• Files will be named like “Domains.Locale.xlf”, e.g. “Error.es-ES.xlf” for the Shop.Notifications.Error domain, and included in the relevant folders (“Shop > Notification” in this example)

Calling Symfony’s translator

Example for a .php file:

Example for a .tpl file:

Example for a .twig file:

Naming variables

That way, translators will have much more context from the source string than before, when they had to guess what was behind these %s.

Please refer to the following pull-requests to see how we worked on the adaptation:

#5722 - Remove PrestaShop Translator Adapter and use Symfony default one #5754 - Adapting the module page #5707 - Adapting the Classic theme #5 - Adapting ImageSlider module

What it means for you

As a developer

If you’re creating new strings, they must use the new trans() method, and have the relevant domain (more on this below). If you’re modifying existing strings, inherited from the 1.6 version, you can adapt it to the new system as you go: make sure it uses the new trans() method, add the relevant domain and name variables according to the new convention.

As a module contributor

If you have 1.6 modules compatible with the 1.7 version, don’t worry! The new system will be compatible with PrestaShop 1.6 translations, so there is nothing to do. Your current translations will still be working. On the other hand, if you’re developing 1.7-specific modules, we encourage you to follow the new standards explained above.

As a translator

Well, it will be much easier to help translating PrestaShop on Crowdin! :)

Crowdin availability

We’re doing our best to upload the 1.7 project onto Crowdin as soon as possible, so that translators will have time to help before the Release Candidate is ready. We’re still running some tests but it should be a matter of weeks now! :) Of course we’ll let you know here on Build when it’s finally there.

Now, your next question should be, “but how do I know which domain to use?”, or “what does it mean when I see one?” Glad you asked!

Domains structure

We’ve organized domains in 4 major sections Shop, Admin, Modules and Install. All the PrestaShop translatable strings are spread across these 4 domains, according to the following definition:

These are called “first-level” domains. They are strictly informational, no domain should be Modules, Shop, or Admin only, as it should have at least two levels. Only strings from the installer have Install only as a domain. Each domain is thus subdivided into sections, more or less according to the complexity of its content.

In the end a domain is like Shop.Theme.Checkout and it will correspond to a specific folder in Crowdin, where you’ll find all the strings from the default theme, related to the checkout process (funnel, shopping cart, etc.).

• In a given source file, several domains can appear.
• For a page displayed (either front or back), several domains can be used.
• For a Crowdin folder, only one domain is called.

Some explanations on how we organized domains and what they contain in details:

Install

That’s the easiest one, there’s only one domain: Install. It’s the content from the installation wizard.

There’s nothing new here, it corresponds to the former “install” file we had in 1.6 project in Crowdin.

Modules

For modules, it’s rather simple. We still have a “Modules” folder (first-level), which contains either a file or folder for each module: this the second level. The third level is here to say whether the string appears in the front office or the back office.

Not all modules have a third level: Some modules only have strings for the back office, so in that case we’d use only the second level domain, e.g. Modules.ImageSlider for the “Image Slider” module, in order to keep it as simple as possible. The strings for these modules will be gathered under a simple file, and not a folder.

In Crowdin, you will then have a mix of files and folders, like this:

Some strings might be rather generic (like “Search” or “Settings updated”) and can be shared with other modules or pages. In that case, we’ll use the Admin. or Shop. domains to avoid unnecessary duplicates. It means that in some modules folder you will see some Admin.Actions or Shop.Theme domains.

Shop

For the front office, it’s getting a little bit more complex. Any string related to the front office goes into a Shop domain. That’s the first level. Then it’s split in various sections, mostly functional. Here’s how it works for the second level:

Each of this domain can be further divided to provide even more context.

1. The Theme section is divided into 4 additional sections:
   • Catalog: all the strings needed to display your catalog (product page, categories, etc.).
   • Customer Account: anything related to the management of a customer account and the orders.
   • Checkout: everything related to the act of buying - i.e. if you’re in catalog mode, you shouldn’t need these strings.
   • Actions: all the call-to-actions, buttons or links that you find on the shop and that aren’t specific to a page or context.
2. The Demo section has only two sections:
   • Catalog: content for demo product and categories (descriptions).
   • Pages: content inside the demo pages (formerly known as CMS pages).

3. Notifications are split according to their level of alert: error, warning or success. They are the messages showing up on your shop.

4. As for the Form sections, you’ll have
   • the form labels,
   • its corresponding errors (distinct from the theme errors, these one are specific to the form and will display inline),
   • and what we’ve called “help” - mainly the hints to help you fill in the form (special characters, etc.).

Admin

Now, let’s see how things are organized for the strings from the back office.

If you’re not familiar with the new sections in PrestaShop 1.7, read this article about the new menu.

From “Orders & Customers” to “Parameters”, the third levels are organized the same way, as functional domains. Each of these third levels will include three sublevels:

• Feature: everything specific to a functional domain. If you’re in the “Shipping” section, the domain Admin.Shipping.Feature will contain all the strings displaying in the Shipping menu, that are particular to these pages.
• Notification: info, success, warning or error messages specific to the functional domain and the pages it includes.
• Help: help text and placeholders.

For example, here’s what it will give for a specific page from the back office (Design > Image settings)

With the following domains being used:

Limitations

While we wanted to have a great system, there are nevertheless a few drawbacks.

• Help texts are now separated from the features. When translating 1.6, the feature string and its attached help text were place one after the other in the Crowdin interface. With the changes in 1.7, these two strings will be in two different files. But we ignored this limitation since separating features and help texts:
  • Allows a better prioritization (= you’d want to translate the features first, which is the core of the software, then the help, which can be seen as a plus)
  • Allows a differentiation in tone (features are often using infinitives and are more neutral, while help is more personal and talks directly to the merchant)
• That’s more files to get lost in on Crowdin, but it’s a trade-off: each file will be shorter to complete and it will provide a better overall context.
• With their new format, the PrestaShop translation files will be heavier. However the .xlf format makes it possible to have the English source associated with its translations. It’s much more convenient to read (before you had only the translations keys, which aren’t very helpful).

Disclaimer: work in progress

There a few things you need to know about this new system, as we’ve just started to deploy it.

• It’s currently being worked on. We’ve started to map the front office and new 1.7 pages (modules, product) with the domains. The rest will come as the beta phase moves forward. In the meantime, strings which haven’t got any domain will fall under a generic “messages.xlf” file on Crowdin. As time will go by, more strings will have domains, and it will move from the “messages.xlf” file to the relevant mapped file.
• We’ve presented here the ideal we want to reach. The reality might differ a bit (= we might not be able to get the demo content in Crowdin after all, this kind of things…).
• Please understand that this system is in beta phase as well. At first some strings might still have duplicates, some will move from a domain to another, etc. We’re in a trial & error mode.

So please bear with us while we’re doing our best to improve things, and if you have any suggestions, they are more than welcome!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 26th of June to Sunday 3rd of July 2016.

General messages

Onward with 1.7! The team is still cranking code, and we’re happy to see more and more people contributing to the codebase!

Have you tested Beta 1 of PrestaShop 1.7?
Have you tried one of your modules in 1.7? Have you tried to create a 1.7 theme? How did it go?
Give us your feedback!

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Do you live near Paris? Do you want to come test-drive the design of PS 1.7? Let us know!

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5774: Improve classic theme integration, by @nihco2.
• 5796: Removed shop name from meta title. Thank you @dh42!
• 5799: Fix slider legends : alt and title attributes should be populated in classic theme, by @mickaelandrieu.
• 5802: Let the modules handle the newsletter subscription, by @maximebiloe.
• 5814: Add last level category for product breadcrumb, by @maximebiloe.
• 5823: Fix product page selected border, by @nihco2.

Back office

• 5136: Fixed parsing of files *.twig for translations. Thank you @true0r!
• 5337: Fix CMS pages permissions. Thank you @fojtcz!
• 5794: Display all combinations to make a product pack, by @maximebiloe.
• 5795: You can exclude already discounted products from voucher. Thank you @kpodemski!
• 5800: Load proper service to get the translator, by @quetzacoalt91.
• 5803: Increase max. length of catalog price rule name. Thank you @antho-girard!
• 5804: Display right tax info in carrier wizard, by @maximebiloe.
• 5815: Increase number of products displayed for pack creation, by @maximebiloe.
• 5822: Empty text field should be submitted, by @mickaelandrieu.

Core

• 5086: Prevent PHP Warning in Tools class. Thank you @kermes!
• 5789: Fixed missing legend property in ImageRetriever, by @mickaelandrieu.
• 5790: Select the cover image and not the first one if set in back office, by @mickaelandrieu.
• 5791: Sprintf support in the translator, by @jtabet.
• 5798: Remove not needed concatenation in meta title. Thank you @prestamodule!
• 5801: Fixed notice invalid role is passed to isGranted(), by @jtabet.

Web service

• 5531: New hook added for adding new resource in webservice. Thank you dks295!

Localization

• 5818: Added some domains for translation, by @jtabet.

• 5819: Replaced

  sprintf: with sprintf= in smarty templates, by @jtabet.

• 5820: Replaced @s{n} with %{n} in translations, by @jtabet.
• 5824: Added a call to the Context’s Translator in module->l(), by @jtabet.
• 5825: Added a call to the Context’s Translator in smarty l() when a domain is provided, by @jtabet.

Installer

• 5793: Added US military base codes. Thank you @dh42!
• 5806: Installer improvement, by @jtabet.

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @antho-girard, @dh42, @fojtcz, @kermes, @kpodemski, @prestamodule, and @true0r! Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

PrestaShop has numerous features in the API, both hidden in its code as well as in the developer documentation and there are many tools that allow you to create your own module in no time! Unfortunately I have noticed that many developers do not use these features and tools to their advantage, so I think it’s time to change all that :) Hopefully, these tips will increase your development speed and save you lots and lots of time. And if not satisfied, you’ll get your money back! (Oh, wait…)

Here is a list of very very useful tools and features. Prepare for some technical stuff as we’re going to cover some of them in depth.

1. Use an Integrated Development Environment

Using an integrated development environment such as PhpStorm or NetBeans is a great way to improve your productivity. Tools such as these come with dozens of nifty features out-of-the-box to develop quicker… a lot quicker!

As the name implies, they intend to integrate as many features as possible, allowing you for example to automatically upload your changes over FTP. It is also possible to make a direct connection with the MySQL database and browse it from your IDE (not recommended for production environments!) to see what was actually written to the database by your module.
An IDE is aware of your code, guiding you while you write your code, wherever and whenever you need it. Cool tip for PhpStorm users: navigate to Help > Productivity guide. It will show you how many keystrokes it has saved you, as well as amount of bugs prevented and hours saved. The numbers will add up quickly after using it for a while! These IDEs were designed to never take your hands off the keyboard while performing basic programming tasks. Feel free to configure the keyboard shortcuts in a way you’re comfortable with and don’t disable the “Tip of the day” messages. They can make the “steep” learning curve of using an IDE a little bit less steep.

2. Stick to coding standards

PrestaShop has changed their coding standards a few times in the past and as of May this year, another coding standard has gone into effect. Why does PrestaShop change its coding standards?
It is mostly because PrestaShop is an open source projects and needs several standards to abide to, because otherwise the whole codebase would become an unreadable mess and the GitHub repository would become a place full of (small) conflicts – no time to actually focus on the software itself. (“What color is the bikeshed?”, “I think it should be PrestaShop purple!” – just to name a few examples!)

The latest standards used by PrestaShop are based on the Symfony standards. By adopting these common standards, it makes it easier to rely on solid and proven guidelines you can use on other projects. Even though these standards are very specific to open source, you can incorporate them into your own workflow as well, in order to increase productivity. There are probably numerous times where a co-worker might have to look at your work and need to adjust your code. Having someone else take a look at your code may apply even if you’re a one man army coder. Using standards makes it much easier to cooperate. Don’t forget that these standards were also designed to make the code somewhat “predictable” and allows for less mistakes, thus making the code you write less error-prone. Isn’t that cool?
If you use these standards and rules that have (originally) been designed for open source projects to your advantage, you’ll definitely save yourself some time!

3. Generate the module’s configuration page

When working with PrestaShop modules you might have seen the fancied configuration pages. Notice how many of them are different? Some include wizard pages or popups, others have millions of tabs to separate the different configuration types.
At first sight, some of them might look cool and you might get tempted to copy these as well, but don’t forget that this will cost you some maintainability. This is particularly true when having to support multiple versions of PrestaShop. The HelperForm and HelperOptions classes were designed to help you with this. Did you know that it is possible to extend these templates and that you can define your own configuration elements? Here’s a code snippet that will allow you to use PrestaShop 1.6’s switch element on an older version of PrestaShop:

You can simply place this file in the location views/templates/admin/_configure/helper/form/form.tpl relative to the root of your module’s folder and the HelperForm template has been extended. Do you see the $smarty.const._PS_VERSION_|@addcslashes:'\''< '1.6' check? This simply allows us to define several templates for different versions of PrestaShop. Pretty cool if you want to keep your code together and the view separated in a different file. It also keeps your main module file readable as you will only need to define an array with the right values in order to generate the form. Remember PrestaShop’s MVC nature? You’re perfectly respecting this pattern by implementing your configuration page this way.

4. Contribute to PrestaShop’s core code

PrestaShop’s core code is baked on GitHub. This is where developers gather and contribute to PrestaShop. Not only do developers contribute code, you will also see some of the visitors comment on your Pull Request. Before your contribution is merged, it will also be checked by PrestaShop’s developers and quality assurance team. Sometimes they might merge your code right away, but it can also happen that your code contains some bugs. The advantage of such an open and transparent process, is that others will see your code (guaranteed, as all pull requests are at least being checked once) and might reveal some bad coding habits you might have developed over time, without you even realizing it. Most contributors visit the GitHub repository in order to improve PrestaShop and the contributions, so the chance of someone suggesting improvements for your code is very high. Use the advice to your advantage!

5. Drop support for older versions

As PrestaShop’s code improves over time, so does the API. The newer the version, the easier it will be to develop a module as PrestaShop’s codebase has evolved over time. It is now much easier to create a module than for example four years ago. By dropping support for older version you will not only enjoy the features of a newer API, you will also have to insert less conditional blocks into your code. In the end, this makes it a lot easier to test and maintain your code.

6. Use open source modules as “boilerplates”

PrestaShop 1.6’s developer documentation, unfortunately, is far from finished as there is enough left to write about. You might have had numerous time where you had wished that the page contained some more information. Luckily, most of the basics can be figured out by having a look at the basic modules on GitHub or other open source PrestaShop module projects. Yes, they exist :)

Here is a starter kit for a payment module for PrestaShop 1.7: https://github.com/PrestaShop/paymentexample

Do you remember the open source Google Shopping module? It’s a very good base for an export module: https://github.com/jmartin82/ps_googleshopping

This module does some very complex thing – it is hard to change PrestaShop’s default URLs: https://github.com/ZiZuu-store/zzCleanURLs

A full and mature open source alternative for using Stripe as a payment method: https://github.com/firstred/mdstripe

Working (and changing) the way hooks are used: https://github.com/firstred/mppaymentstocarriers

Replacing PrestaShop’s default search with ElasticSearch: https://github.com/DonatasL/PrestaShop-ElasticSearch

These are (in general) complex and/or extensive modules. Search around on GitHub for more projects like that. They can really give you a headstart when working on a new module. Be sure to always check the code license, however. Some licenses might prevent you from using the code in future (commercial) projects!

7. Avoid “magic numbers” and “magic strings”

When creating a module for PrestaShop there will be dozens of times in which you will need to access a configuration key (e.g. Configuration::get('MYMODULE_ACCEPT_PAYMENTS')). By using strings all the time you increase the chance of making a typo. Since these strings never change during runtime you can define them as constants at the top of your module’s class. By using an IDE which immediately warns you when the constant cannot be found, it’s easier to prevent bugs. You can define the constants as follows:

class IndexControllerCore extends FrontController
{
	const ACCEPT_PAYMENTS = 'MYMODULE_ACCEPT_PAYMENTS';
	
	public function __construct()
	{
		// CONSTRUCTOR
	}
}

Configuration values can now be loaded like: Configuration::get(self::ACCEPT_PAYMENTS). You can do the same for “magic” numbers. If you use numbers which do not change during runtime, make sure that you turn those into constants, as much as possible.

8. Create a Gruntfile

Not necessarily a direct improvement for your code, but it allows you to pack your modules with ease, thus saving you time which you can then spend on improving your modules instead.

Here’s an example of a Gruntfile:

9. Use the validator

This is a very simple one. You can use the validator at https://validator.prestashop.com/. It will show you if your module could use some improvements. It doesn’t cover all cases and might miss some problems you might have in your module, but it will give you a basic understanding of the improvements you will need. Not everything is equally important. Focusing on security has (of course) a higher priority than having enough spaces before a single opening bracket. Use your best judgement!

10. Go for automated testing

A human can only test so much. If you have a lot of repeating tasks that can be easily handled by a continuous integration server such as Jenkins, use it! It’s not going to be covered in detail in this blog post, but here are a few steps to get started with automatically testing PrestaShop modules:

• Install Jenkins
• Configure it in such a way that it
  • clones PrestaShop’s repository
  • clones your module into the modules directory
  • automatically installs PrestaShop
  • uses a testing framework such as Codeception in order to unit, functional and acceptance test your module
  • is used together with Selenium in order to see the actual steps

By beginning with a simple acceptance test that installs your module, you will immediately get feedback on the installation process of your module and bugs in that area will be visible immediately. Another advantage of using a continuous integration server is that you can define massive build matrices that will allow you to test on e.g. PHP 5.5, 5.6 & 7.0 + PrestaShop 1.5.0.17 - 1.6.1.6 simultaneously. No more need to manually test the installation process on all these versions. You can now spend this time on further improving your module instead.

Did these tips help you create module faster? Do you still have some questions? Was there a step too hard? Let us know in the comments!

Last year PrestaShop launched its 1$ Million Integration Fund, conceived as a way to support a selection of developers by granting them funds to develop local modules. At the Paris PrestaShop Day 2016, we celebrated the first anniversary of the program.

Here are the figures that we achieved together with contributors from all over the world: $200,000 were granted to fund 130 modules that improve PrestaShop stores in more than 100 countries.

It is still time to get involved

There are a lot of great development opportunities everywhere in the world. To help you pick a project to suggest, we summarized the priorities for the next few months regarding countries and module categories.

If you are a developer in one of those countries, have a look at the table below: we have listed which type of modules can be helpful to merchants in your region. We assume local developers are the best able when it comes to know what services are mostly used in their country.

You can also contact us thanks to the integration fund application form here: https://addons.prestashop.com/en/integration-fund. We sometimes have module ideas that are waiting to be developed.

Meet a contributor

Daniel comes from Romania, and has developed several modules through the Integration Fund. Thanks to him, Romanian merchants can benefit from useful functionalities in their own language, such as the eMag Marketplace module. This is what he told us:

The PrestaShop Integration Fund is an excellent project. It gathers developers, merchants, sellers and enthusiasts to help this awesome CMS grow even more. And the fact that everyone wins is truly awesome.

Personally, when I first saw this project I said to myself: “Wow! I gotta be part of this!”. I started making some researches, then identified the needs and developed the modules. And now, here I am, witnessing and contributing to the ascension of PrestaShop.
I am proud to be a member of this huge community, I am one in a million more exactly :)

Be a part of it, apply now!

Find more information and the submission form here: https://addons.prestashop.com/en/integration-fund.

Big news! Translations for PrestaShop 1.7 are now available on Crowdin.

It means you can start translating PrestaShop 1.7, to make sure it’s available in your language when this new major version is released!

Translate PrestaShop 1.7

As a reminder, PrestaShop 1.7 is still in Beta phase.

Here is what you need to know about the 1.7 translations.

1. There is a new translation system, which uses domains

Please read this full article to know more about it. The big changes are that:

• There will be more files in Crowdin
• These files will have less strings than the 1.6 ones
• They will provide more context
• And we’ve done our best to reduce duplicated strings (= that’s less strings to translate)

2. Any string already translated in 1.6 and still in 1.7 will be marked as translated in 1.7 too

We’ve taken advantage of Crowdin’s translation memory system to make sure we don’t lose any translation. If a string is the same in 1.6 and 1.7, and it is already translated, it will show as translated in 1.7. No need to do the same work twice!

For the languages which are already 100% translated for 1.6, it means that only the new 1.7-specific strings will need to be translated. That’s mostly the new theme, the new Modules page and the new Product page: only 20% of the current project (about 7,700 words to translate, to be exact!).

3. Everything isn’t there yet…

… but it’s coming! As we’re still implementing the new system, some content won’t be available in the 1.7 project at the beginning:

• Emails
• Some error messages
• The new menu

It will be uploaded as the project moves forward. So don’t expect a linear progression of the percentage of translation at first.

4. Translations are in beta phase

The fact that we’re dealing with a new translation system AND that the 1.7 version is still in beta phase means that some things aren’t perfect and might change.

• Some strings might evolve as we release new beta versions.
• Some strings do not have any domain yet. For the time being they are in the “messages” file. They will eventually be placed in the proper domain.
• All the modules aren’t organized in their respective folders yet. Their translations are available in the “messages” file in the meantime.
• We’re still testing how the propagation works (if you translate something in 1.7, will it be translated in 1.6 too? Or is it the reverse?). Stay tuned!

5. Language packs aren’t available yet

This is also something we’re working on. As we’ve introduced a new translation system, the PrestaShop-to-Crowdin part is up and running; and we’re now focusing on the Crowdin-to-PrestaShop part. Language packs won’t be available at first, so you won’t be able to retrieve your translations and have them in your 1.7 shop in the beginning. We’re aware it’s not for the best as of now, but don’t worry: solving this is among our top priorities!

Of course we’ll keep you updated and let you know as soon as something new comes up. We’ll update the project as it goes so that you always benefit from the latest changes.

Now is the time to translate PrestaShop 1.7 :D

Thank you for your contribution to the PrestaShop project!

Translate PrestaShop 1.7

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 4th to Sunday 10th of July 2016.

General messages

We’re getting real close to a Beta 2 release? Are you ready? :)

Have you tried one of your modules in 1.7? Have you tried to create a 1.7 theme? How did it go?
Give us your feedback!

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Do you live near Paris? Do you want to come test-drive the design of PS 1.7? Let us know!

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5812: Submit current step form when clicking on a next step title, by @maximebiloe.
• 5817: Fix product refresh when changing quantity, by @maximebiloe.
• 5832: Fixed user registration if guest user exist with same email. Thank you @fojtcz!
• 5840: Refactor classic theme CSS, by @nihco2.
• 5844: Wording and rewriting variables for Classic Theme, by @alexeven.
• 5852: Fix displayHeader hook called twice. Thank you @fojtcz!

Back office

• 5811: Migrated “prefered modules” action to Symfony, by @mickaelandrieu.
• 5826: Fixes some fatal in AdminStatsController, by @maximebiloe.
• 5828: Button to add an address from the customer profile. Thank you @alblanc!
• 5833: Fix fatal error on calling TranslatorComponent, by @maximebiloe.
• 5843: Fix fatal on order view - Use sprintf instead of tags, by @maximebiloe.
• 5845: Add translation domains to controllers, by @alexeven.
• 5849: Fixed enable/disable mobile bulk actions on modules, by @mickaelandrieu.
• 5850: Fixed Service label on module read more modal, by @mickaelandrieu.
• 5851: Fixed CTA action on read more modal in Module list, by @mickaelandrieu.
• 5855: Fix call to undefined method trans(), by @maximebiloe.
• 5856: Fix wrong parameters number in sprintf, by @maximebiloe.

Core

• 5837: When string uses domains sprintf() must be an array and tags() must be removed, by @maximebiloe.
• 5839: Introduce trans() method in Admin controllers, by @julienbourdeau.
• 5848: Introduce trans() method in every controller, by @julienbourdeau.
• 5854: Add Translation Extractor configuration, by @julienbourdeau.

Tests

• 5838: Fix install in cli mode when paramaters.yml does not exist, by @quetzacoalt91.

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @fojtcz and @alblanc! Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

We are happy to announce that PrestaShop 1.7.0.0 is now available for testing in its 2nd Beta version. More than ever, we need YOUR feedback as a merchant, a service provider, a module developer or a theme designer.

The release of this second Beta version is another important milestone in the current period of intensive testing and debugging by the PrestaShop developers.

Test PrestaShop 1.7.0.0 Beta 2 now!

PrestaShop 1.7.0.0 is still in development, which means that this new Beta release is a great opportunity for you to discover it before we release a stable version!
Go download and install the Beta 2 version as a test store, either on your machine or your web hosting, then play with it – and give us your feedback!

While all hands are on deck, we couldn’t do it without the help of the whole community: we need YOU to test this new version of PrestaShop.
Change the settings, browse the default theme, check if the modules that you created still work as-is (or with tiny design adaptations), etc. And most importantly, let us know about your findings!
Update your module’s code if needs be, and check out the current theme documentation (still in Beta too - let us know if something is amiss!)

How to give feedback about Beta 2

Have you found a bug? A curious behavior? An unexpected reaction? Let us know! Create a ticket on the 1.7 Forge project, and give us as much details as possible!

Please note that we are not looking for feedback on the overall technical or design choices: Symfony2, the new theming system, the back office design and other global aspects of 1.7 are pretty much set in stone. However, do let us know about bugs or possible improvements!

Updates since Beta 1

Here are the most notable changes since the first Beta version:

• 4921: “Manufacturers” menu is now “Brand”.
• 5583: Maintenance text can be customized from the back office.
• 5702: The conditions page is not a CMS page anymore.
• 5711: The translation system now uses Symfony’s Translator component.
• 5777: The Symfony error/exception handler is now availables in front office.
• 5774 and 5840: Classic theme integration improvement and refactoring.
• 5779: The Cart now handles virtual products in a more sensible way.
• 5794: Display all combinations to make a product pack.
• 5795: You can exclude already-discounted products from a voucher.
• 5827: Improved the Product page image dropzone.
• 24 pull requests to implement the new translation domains.

See the complete list of merged PRs since building Beta 1 (May 27th) here.

Final note!

A lot of work went into this new Beta of PrestaShop 1.7, and there is still a lot of work to be done in order to get it ready for release. You too can help with pull requests for bugs that you noticed!

Happy testing!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 11th to Sunday 17th of July 2016.

General messages

We released Beta 2 of PrestaShop 1.7! Ain’t that cool? :)
Let us know what you think!

Also, the new Symfony-based (and domain-based) translation system is up and working: you can start translating PS 1.7 already!

Have you tried one of your modules in 1.7? Have you tried to create a 1.7 theme? How did it go?
Give us your feedback!

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub);
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!);
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue);
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Note that between Beta 2 and the Bastille Day, it was a slow week :)

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5867: Adding domains to FO classes, by @alexeven.
• 5871: FO: Fixing domains for classes, by @alexeven.

Back office

• 5827: Adapt the dropzone on the design of the product page, by @quetzacoalt91.
• 5853: Add translation domains to controllers, by @alexeven.
• 5858: Update module cards button design, by @nihco2.
• 5864: Fix undefined trans method, by @maximebiloe.
• 5873: Fix NaN on product price and image settings position, by @maximebiloe.

Installer

• 5857: Fix translation domain in installer, by @alexeven.

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets and comments on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

Here is the latest report to inform you of what has been going on PrestaShop translation project on Crowdin in June. It’s coming a bit later than usual, but we’ve been busy, as you’ll see!

Project news

Translations for PrestaShop 1.7

One big news is that we recently uploaded translation for PrestaShop 1.7, so there’s more translation to do! Read all about it here. The other information is that we’re using a new translation system, so the project organization is different (and hopefully more convenient for translators). You’ll find all you need to know in this article.

Updated 1.6 translations

As planned, the 1.6 translations have been updated 2 weeks after the last update, on the 19th of June. Next update should be around the 2nd of August.

Rulebook for Romanian translation

The Romanian community has been talking together to agree on a few rules to follow for a better translation. You can join the conversation on the forum.

So far it has been decided that:

• The Romanian translation will not use diacritics
• The Romanian translation will not use honorifics

Consequently, some editing and harmonization will be going on in the Romanian project. We hope to provide an online ressource where you can find the results of these discussions soon. Stay tuned!

Now let’s get back to our Crowdin project, and the full report of its activity in June:

A few stats

• 35 contributors joined the project this month, for a total of 2,846 members at the end of June. Welcome to them!
• 34 members were active on the project this month.
• A total of 26,235 words have been translated (+46%) and 27,280 validated (+ 174%!!).
• All this in 23 different languages.

Thank you for your involvement!

Top contributors

A lot of you are working everyday on Crowdin to have PrestaShop available in many languages, and we can’t thank you enough for your dedication! Here are the most active translators and proofreaders this June.

Top 10 translators in June:

Top 10 proofreaders in June:

A big applause to them! And welcome to our new top contributors!

Complete translations

Fully translated languages

At the end of June, PrestaShop 1.6.1 was fully available (= 100% translated and validated) in 18 languages:

• Bulgarian
• Croatian
• Czech
• Dutch
• English
• French
• German
• Indonesian
• Italian
• Lithuanian
• Norwegian
• Persian
• Polish
• Russian
• Slovak
• Slovenian
• Spanish
• Swedish

98-99% translated languages

PrestaShop was also almost fully translated (and/or validated) in these 5 languages:

• Greek
• Portuguese
• Portuguese, Brazilian
• Romanian
• Vietnamese

A little bit of work and these languages can be 100% translated and validated too! If you feel like you want to help, join the project!

Languages with the best evolution

In comparison with May 2016, the following languages had the best progress in June:

• German, Luxembourg (+16.7% to reach 7% translated)
• Galician (+2% to reach 50% translated)
• Chinese, Traditional (+1.3 to reach 78% translated)
• Spanish, Colombia (+1.3% to reach 79% translated)

Of course this is highlighting the languages that made some progress with new translations; but it doesn’t mean that the languages that aren’t mentionned here aren’t active. Indeed, some editing and rewriting could be going on, but the % of translation wouldn’t be modified (since it’s working on strings that are already translated). So let’s not forget about the work of these proofreaders! Thank you too!

Languages that need (more) proofreaders

A translated string will not be available in PrestaShop as long as it is not validated. For this reason, it’s important we should keep a good level of validated strings vs. translated strings, to make sure everyone benefits from the latest translations!

At the end of June, 7 languages would still benefit from more proofreading:

• Turkish (100% translated vs 40% validated - which is much better!)
• Greek (100% translated vs 81% validated)
• Romanian (100% vs 87% - in progress!)
• Ukrainian (100% vs 53%)
• Hungarian (92% vs 72%)
• Arabic (54% vs 28%)
• Galician (50% vs 11%)

If you wish to help proofreading what has been translated, please contact me on Crowdin with the language you’d like to proofread. We need your help!

If you haven’t joined us on Crowdin yet, it’s never too late!

If you want to gather your fellow translators to work towards a better harmonization, start a glossary, or anything else, do let us know: we’ll include a word about it in the next monthly report.

Do you have a question, a remark? Don’t hesitate to leave a comment. See you next month!

PrestaShop has been around for many years, during which thousands of modules were made by thousands of developers, yet we still see the same simple mistakes being made, even though they could easily be avoided.

Here is a list of 10+ common mistakes when coding a PrestaShop module, with a short information on how to avoid them.

• 1. Creating/using a module with hardcoded database prefix
• 2. Making sure your module can be translated
• 3. Data validation - do not trust your users or yourself!
• 4. Setup module compatibility and restrictions
• 5. Do not trigger code if it is for a specific page
• 6. Too much going on in your __constructor
• 7. Conflicts, conflicts everywhere!
• 8. Your module has front office controllers but you didn’t register them…
• 9. Weird ways to do module updates
• 10. Lack of multi-lang, multi-store support
• 11. Ignoring/not knowing PrestaShop Validator
• 12. Inventing the wheel again

1. Creating/using a module with hardcoded database prefix

This can be surprising to some but, yes, I saw this a few times: developers using the “ps_” prefix in their SQL schemas, or SQL queries.

How to avoid this? Always use PrestaShop’s _DB_PREFIX_ constant, which is the prefix that is defined by the user during installation.

2. Making sure your module can be translated

PrestaShop 1.6 has an amazing translations system. Users can easily translate themes and modules from their back office, but not all themes/modules are available there, why so? Some module developers still forget to make their creation translatable, or make mistakes by using not the proper code for a translation.

Remember:

• Translations inside module files: $this->l('Translatable text')

• Translations inside the module’s back-office controller (which extends ModuleAdminController): $this->l('Translatable text')

• Translations inside the module’s front-office controller (which extends ModuleFrontController): $this->module->l('Translatable text', 'controller_name')

• Translations inside mails: Mail::l('Translatable text')

• Translations inside PDF files: PDF::l('Translatable text')

Remember to use English as your default language in translations! Indeed, it is always easier to find people to translate from English than other languages.

Note that PrestaShop 1.7 completely updates the way translation is defined.

3. Data validation - do not trust your users or yourself!

Recent events show that even the most popular modules or themes can be affected by security flaws and exploited by hackers. There are a few simple steps which will help you keep your modules secure:

• Always check the input data: use Tools::getValue('var') instead of $_POST['var'], $_GET['var'].
• Type hinting makes sure the value has the correct type: use (int), (bool), (float) properly, check the public methods available in the classes/Validate.php file, such as isUnsignedInt().
• The PrestaShop token is your friend: always check the token when doing action for logged in customers. Need an example?

You can also check the token for guest users: I suggested these two methods.

• Secure your files: files outside your module’s base file (such as ajax.php, upload.php, etc.) should have a check at their very beginning in order to make sure they cannot be triggered directly. Here is example:

4. Setup module compatibility and restrictions

Let’s be honest, sometimes it’s hard to maintain a module from version to version, and sometimes you’d like to release a module only for specific versions of PrestaShop, even specific countries!

How to set the compatibility of your module? In your __construct method:

$this->ps_versions_compliancy = array('min' => '1.6.1.0', 'max' => _PS_VERSION_);

This code will not allow to install the module if you have PrestaShop in version lower than 1.6.1.0.

How to restrict your module for specific countries? In your __construct method:

$this->limited_countries = array('fr', 'pl');

This code will not allow to install the module in countries other than France and Poland. Use ISO-3166 codes!

5. Do not trigger code if it is for a specific page

If you are using the displayHeader hook to add features to the Product Page (for instance), do not use this code if you’re not on page where you have a single product.

You can easily contextualize your code by simply using if statements:

public function hookDisplayHeader($params)
{
    // A good practice is to stop code as soon as possible if we don't need it.
    if ($this->context->controller->php_self !== 'product') {
        return;
    }

    // Rest of the code
}

Quick tip: it’s worth noting that if you want to get some information from the Product object, you can do this with this code: $product = $this->context->controller->getProduct().
There is no need to do new Product(...). This code will work on a single-product page.

6. Too much going on in your __constructor

Yes, this can be tricky. Very often I see modules where developers try to do some stuff in the __construct method of their module. It is Not Good. Definitely. Why? Because this code will therefore be triggered on the front office, the back office Modules page, and a few other pages. Be responsible, place your code in hooks, or target a specific page like it was described in point #5.

7. Conflicts, conflicts everywhere!

So you’ve created an amazing carousel with products selected from back office, proudly using owlCarousel, slick.js or any other popular library. Great!
Now a customer bought another carousel module, one with product reviews, and it turns out that this module is using the same library: now nothing is really working.

What can we do to avoid this problem? Well, there’s no 100%-safe solution for this problem, but you, as a Good Developer, can be nice to other developers (or theme authors), and allow your customers to disable loading of libraries from your module. Take the time to add a section in your Settings called “Troubleshooting” for example, and create a settings where your user can select which libraries can by turned off from your module.

8. Your module has front office controllers but you didn’t register them…

…and if that’s a case, your user cannot set where the left or right column should be displayed. If you’re using front office controllers within your module, remember to register them properly in your __construct method:

$this->controllers = array('my-controller', 'other-controller');

9. Weird ways to do module updates

The day has come, you have a new version of your module and you’d like to change its database schema, add some new hooks etc. There’s no need to implement your own update mechanisms, PrestaShop already has one!

Let’s assume that you have MyModule v1.0.0 and you’d like to update it to v1.1.0, this is example file:

You need to remember about few things:

• This code will fire only if your current module’s version is 1.0.0 and you visit the Module’s page.
• You have access to the $object variable, which is simply an instance of your module.
• You always should return a boolean (true or false): this will trigger the success or error message in the back office.

As you can see, you can create migration of the database, change configurations, add new hooks and do almost everything you need to do while updating your module to the next version.

Quick note: if you add a few version-specific files (for example: install-1.1.0.php, install-1.2.0.php), they’ll run one after the other. Make sure that you check if a target database table exists, or a file exists: it is easy to break something here if you’re not careful.

10. Lack of multi-lang, multi-store support

This is real problem. Many modules are not compatible with PrestaShop’s multi-store feature, even its multi-lang feature. Customers just cannot use these modules in their specific situation.

There are many examples on how to create a module which is compliant with PrestaShop’s multi-store feature, take some time and check how it’s done in modules like: homeslider, blocklink, blocktopmenu and many other native modules.

11. Ignoring/not knowing PrestaShop Validator

Did you know that PrestaShop has a pretty good validator for your PrestaShop modules? No? Visit validator.prestashop.com and test your module today.

You’ll avoid many basic mistakes while creating your module, as some rules are… doubtful :) There are many things which can be fixed thanks to the Validator.

Even if you don’t agree with some of its rules, you shouldn’t ignore the Validator completely: it is a good start for checking if your module is compliant with PrestaShop’s standards.

12. Inventing the wheel again

You’d like to do ajaxed autocomplete? Or maybe create a settings form for your module? Check how it’s done with native modules, be familiar with HelperForm, HelperOptions, and read code! Read the code of the Core, analyze native modules, analyze open-source modules.

Developers often don’t know how something is constructed, and they are willing to sit for 2-3 hours more in order create something by themselves, without reading how it’s already done in different modules or places of the back office. If you want to be a better developer of PrestaShop’s modules, look how many features and tools PrestaShop’s API already provides you with.

Did these tips help you create better modules? Do you still have some questions? Was there a step too hard? Let us know in the comments!

This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase during the previous week, from Monday 18th to Sunday 24th of July 2016.

General messages

We released Beta 2 of PrestaShop 1.7 last week! Did you take the time to have a look at it?

Want to help things go faster? There are several ways:

• Test the Beta version (or better, test the current development version, straight from GitHub).
• Report issues on the Forge (or confirm issues that are already listed - use the search engine!).
• Fix issues by submitting a pull request (or confirm that a submitted pull request does indeed fix the presented issue).
• Help improve the 1.7 tech documentation (both for themes and modules), with issues and pull requests.

You can find an up-to-date thread about the 1.7 development in the forum.
The 1.7 Project FAQ is always available here: http://build.prestashop.com/news/prestashop-1-7-faq/.

Code changes in branch develop (for version 1.7.0.0)

Let’s review the merged pull-requests on the ‘develop’ branch since the last Core Weekly Report!

Front office (including the default theme, named “Classic”, based upon the Starter Theme)

• 5870: Add taxes to modal and a link to product detail in summary, by @paeddl.
• 5874: delete call to Tools::safePostVars() on FrontController::display(), by @rgaillard.
• 5879: Prevent hooks displayMaintenance & displayHome to be called twice, by @rgaillard.
• 5882: Design optimizations in cart and checkout, by @paeddl.
• 5883: Header cleanup, by @ishcherbakov.
• 5884: Fix the page reload when you click on edit during the last checkout step, by @maximebiloe.
• 5888: Display shipping costs even if they are free, by @maximebiloe.
• 5892: Improved design of product price label, by @maximebiloe.
• 5893: Indicate carrier delay on order confirmation, by @maximebiloe.
• 5898: Fix a fatal error during an order validation with a product with a unit price, by @maximebiloe.

Back office

• 5836: Applied 6 decimals for all money inputs in Back Office, by @mickaelandrieu.
• 5861: ix query export in SQL Manager. Thank you @antho-girard!
• 5869: Improved module sorting options, by @mickaelandrieu.
• 5880: Fix fatal in some admin controllers, by @maximebiloe.
• 5886: Rename ‘opt-in’ into ‘Partner offers’, by @maximebiloe.
• 5887: Fix a syntax error in JS form.js preventing the product page display, by @maximebiloe.
• 5890: Fix breadcrumb links, by @julienbourdeau.
• 5891: update optin wording, by @julienbourdeau.
• 5895: Fix undefined trans(), by @maximebiloe.
• 5896: Fix undefined method trans(), by @maximebiloe.

Core

• 5161: Fix webservice POST api/products for PHP7: Function name must be a string. Thank you @tomcyr!
• 5876: Create robots.txt. Thank you @txmodxoops!
• 5878: Use full domain for message catalag, by @julienbourdeau.
• 5885: Fix trans() when no domain is set, by @julienbourdeau.
• 5889: Remove password variable from emails, by @maximebiloe.

See all the PRs merged into the codebase since the last Core Weekly here.

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @antho-girard, @tomcyr and @txmodxoops!
Also, thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with tickets and comments on the Forge!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• How to write a commit message

…and if you do not know how to fix an issue but wish to report it, please read this: How to use the Forge to contribute to PrestaShop. Thank you!

Happy contributin’ everyone!

Hot on the heels of Beta 2, here’s PrestaShop 1.7.0.0 Beta 3, ready for you to test and give feedback about!

As always during this period of testing and fixing, we need feedback from any merchant, service provider, module developer or theme designer who is reading this.

The release of this Beta 3 is another step in the current period of intensive testing and debugging by the PrestaShop developers, towards a proper RC and eventual release.

Test PrestaShop 1.7.0.0 Beta 3 now!

PrestaShop 1.7.0.0 is still in development! This new Beta is a way for us to give you an updated package to test before we enter the RC phase. Go for it!
Install the Beta 3 version as a test store, then play with it – and give us your feedback!

We know there are plenty of issues that must be lying around, and many “quick wins”, meaning things that can be solved with a simple PR and which have a positive impact for the user. And this is where YOU can play an important part! We welcome big fixes with pleasure and cookies :) Go forth and make that PR!

Change the settings, browse the default theme, check if the modules that you created still work as-is (or with tiny design adaptations), etc. And most importantly, let us know about your findings!
Update your module’s code if needs be, and check out the current theme documentation (still in Beta too - let us know if something is amiss!)

How to give feedback about Beta 3

Have you found a bug? A curious behavior? An unexpected reaction? Let us know! Create a ticket on the 1.7 Forge project, and give us as much details as possible!

Please note that we are not looking for feedback on the overall technical or design choices: Symfony 2, the new theming system, the back office design and other global aspects of 1.7 are pretty much set in stone. However, do let us know about bugs or possible improvements!

Updates since Beta 2

Here are the most notable changes since the second Beta version:

• 5865: Multiple integration bugfixes.
• 5868: Asynchronous loading of product combinations.
• 5870: Add taxes to modal and a link to product detail in summary.
• 5882: Design optimizations in cart and checkout.
• 5886: Rename ‘opt-in’ into ‘Partner offers’.
• 5889: Remove password variable from emails.
• 5893: Indicate carrier delay on order confirmation.
• 5909: Upgrade an uploaded module when already installed.
• 5911: Do not display new products in the BO listing until they are saved.
• 5920: Disable bulk action while combinations are loading.

See the complete list of merged PRs since building Beta 2 (built on July 13th) here.

Final note!

A lot of work went into this new Beta of PrestaShop 1.7, and there is still a lot of work to be done in order to get it ready for release. You too can help with pull requests for bugs that you noticed!

Happy testing!