Installing OXID eShop
OXID eShop is web software, mostly written in PHP. The installation should be as easy as a charm on any web server as long as the system requirements are fitting. Please also see this document for detailed settings.
- Download OXID eShop, upload the downloaded file to the web server of your choosing and unpack the files
- Create a database
- Point your browser to the location you uploaded OXID eShop and follow the setup routine
For the installation of an update, please see the tutorial OXID eShop update installation.
Changing functionality with modules
Whenever you want to extend the default functionality of an OXID eShop installation, you should look for existing modules (AKA plugins or extensions), this may save you a lot of time. In case no module meets your demands, the OXID API allows you to code your own module. The module system allows you to write them in a way that the core functionality of OXID eShop has never to be touched, hence your system will stay updatable if you work properly.
Please follow these links for decent tutorials teaching you on how to write an OXID eShop extension:
- In this article on PHPBuilder.com Andreas Ziethen describes the installation, the architecture and how to write a module for OXID eShop using an example.
- In part 3 of Matthew Setter’s series at SitePoint, he is going to get some hands-on experience with OXID by writing a custom module to extend the core functionality. The functionality he is implementing will enable the display of the latest tweets from a twitter account, based on a new custom field added to the administration backend.
- In this 2-part tutorial, Anh Ho describes the creation of a new OXID module extension that implements infinite scrolling to the article list instead of traditional pagination.
- Learn step-by-step how to easily generate a module for displaying content saving on the product detail page of your OXID eShop installation, if you entered a recommended retail price as well as your price. You will also learn how to embed your own CSS and how to make your module multilingual.
- Learn how to write a very simple module for OXID eShop: round up the price on the product details page to five cent. Simply copy an existing method and overwrite it with your additions.
Working with themes
Themes consist of a set of interlaced template files (*.tpl) and control the layout and design of your OXID eShop. As a template engine, SMARTY2 is used.
Your installation comes with the standard themes “Azure”. In general, there are two different ways to get your own, custom template: cloning the Azure theme or creating your own template set from scratch.
It´s strongly recommended to choose one of these options. Do not ever modify the original template set!
The override system works really simple: it uses all template files from the father theme in the original directory, except of those, which are in your custom directory. So you just have place the modified files into the child theme directory, further updates will not overwrite your changes.
The other possibility is to develop a completely own template set and integrate it into the shop. The override functionality will work with this new one as well.
Check out this blog post about theme management in OXID eShop.
Starting with OXID eShop Version 4.6.0, there is an easy way to find out which template file is responsible for what output in the frontend, just set
in config.inc.php and template name and path will be displayed at the store front.
For OXID eShop, major releases (e.g. x.9.0), minor releases (e.g. 4.x.0) and patches (e.g. 4.9.x) are provided. All of this releases belong to a series (e.g. 4.9 or 4.8).
Please note that presently the series are separated: OXID eShop Enterprise Edition is using series 5.x while Professional and Community Edition are series 4.x.
Major and minor releases may contain changes in architecture, database, core and language files as well as in templates (store front and admin). Update scripts and a beta version will be provided, releases to expect roundabout once a year. No matter which edition you run.
However, patch releases are usually published in order to fix bugs. There will definitely be no changes in architecture nor database, and in the most cases not even changes in store front templates and language files. Just core files and maybe admin templates plus language files might be altered. There will be no beta version; update scripts will be provided. Releases happen quarterly. No matter which edition you run.
Supported versions and cumulative update packages
Supported and maintained versions are always the latest patch releases of a series and the one before.
For example, if version 4.9.5 is the present version in 4.9 series and 4.8.7 is the latest patch in 4.8 series, the next patch would definitely be 4.9.6, but 4.8.8 only if a serious or security related bug was fixed. The series 4.7 with it’s latest patch release 4.7.14 will definitely not be supported and maintained any longer to patch release 4.7.15.
In case there will be released a new minor version 4.10, it will start with 4.10.0. From this point on, the 4.8 series will reach end of life status and will not get any patches no more.Please note that cumulative patches will only include the latest patch release within one series like 4.8.6 to 4.8.7 or of the one series to a newer series, for example 4.8.7 to 4.9.5. Also 4.8.7 to 4.9.6 would be provided, but never 4.8.5 to 4.9.6.
New releases will at least be officially announced via the forums, dev-general mailing list, Twitter, Facebook, and Google+. However, clients with a support contract, official partners and NDA owners will additionally be informed via email.
Continuous integration and automated testing
In core development, we use Jenkins for our continuous integration and continuous distribution process as well as for package building. With Jenkins, it is possible to integrate any tests like PhpUnit and Selenium and check in nightly builds what has been developed over the day on several environments, for example PHP-versions. Unfortunately, this server is not publicly available.
If you provide pull requests via GitHub, your code will also be checked with the publicly available Travis service. In case the build turns red, please check if you’d have to provide or adapt unit tests for your contribution.
The OXID eShop testing library is intended to be used by developers to test their OXID eShop developments and/or extensions with existing or new PhpUnit, Integration, Mink (Selenium) or QUnit tests.
OXID eSales is an Open Source software vendor and naturally takes security issues serious. Please use the following page to find information on how to report security-related issues to us and how we process such issues:
User help & merchant documentation
If you’re an online merchant or a user looking for help, please consult these pages:
Source code & DB documentation
With OXID eShop, you’ll find a very fine grained source code documentation, automatically extracted from annotated PHP sources with doxygen. Please find an overview on this page:
Another very important source for you might be the database documentation for the different series: