This add-on adds some extra groovy features to Event Espresso.
Note, this add-on is unreleased and in active development. Use at your own risk and it likely won't work.
Note, there is no usage support provided here. Please read the entire contents of this document before posting any issues. If we encounter issues that give evidence of this document not having been read the issue will be closed.
| Some Links | |
|---|---|
| Support License | Support for this add-on is not provided through this repository. For support you can purchase a Premium Support License. |
| Documentation | View Documentation → |
| Newsletter | Be the first to know when we ship new features ... signup here. |
| Community Chat | Join a real-time community chat group for professionals that are leading the way in events from event management, event technology and event marketing to work-life balance. Join the Discussion → |
This is the full version of the add-on and provides its full feature set. The repository is provided to assist you with evaluating whether it will solve your use-case.
We ask if you are using this to provide a solution for clients that you (or your client) purchase a support license for this add-on.
No Usage Support is provided in this repository.
We follow a set pattern for releases and development of all our official add-ons:
- Active development for new features happens on a FET-{ticket-number}-{brief-description} branch. We continually merge master into the feature branch while it's in development. Once it's complete, then testing is done on it and it's merged back to master ready for release.
- Bug fixes are done on a BUG-{ticket-number}-{brief-description} branch. Same methodology is used as with feature branches.
- Master is technically always production ready and release ready but may not be equal to what the current stable release is for.
- When we do an official release of an add-on, the current master is tagged and the release is the zip for that tag.
For all testers of this add-on, please take note of the following when reporting issues.
-
There is a difference between a feature and a bug, we consider a bug is something that reveals brokenness in intended functionality. A feature, is something beyond intended functionality. To help determine the difference, think about your issue like this, "I know A does C, however I wish it did D." If you find yourself saying that, its a feature. This repository is not the place to suggest a new feature UNLESS you've already got a pull request to implement it (see pull requests section below). Info on sponsoring new features can be found here. If you aren't sure whether something is a feature or bug feel free to post the issue - however we give priority to bug issues here.
-
UI/UX issues may be considered a bug but not if it requires a major change in design. Feel free to report things you find confusing or needing improvement however reports accompanied by a pull request will likely get faster attention.
-
Report your issue as clearly as possible. By "clear" we mean:
i. Specify the branch this occurred in.
ii. Be specific about the steps you took to reproduce.
iii. Feel free to use screenshots/screencasts to illustrate
iv. Use URLs for the page the issue to place on where possible.
-
Don't "bump" bug reports if we don't respond right away. We see every report coming in, but we'll only reply if we need clarification or if we think its invalid. Otherwise, we're likely working on a fix and the issue will be updated when the fix is complete.
One of the reasons we created this private repo on GitHub is because we wanted to open up EE development to 3rd party developers who might want to contribute to the codebase. GitHub makes this really easy to do so via pull requests. If you don't know what pull requests are, please read up on them via the GitHub help/documentation.
Here's how we deal with pull requests for our repo:
- Any new FEATURES in a pull request should be based off of the master branch. If your feature pull request is based off any other branch it will not be considered.
- Any BUGFIX pull requests should be based off of the branch the bug was found. Please verify if it is in master before submitting the pull request. If it is in reproducible on master, then the pull-request should be based off of master.
- We greatly appreciate any pull-requests submitted for consideration, but please understand we are very selective in what we decide to include in our official add-ons. If the "feature" is something that expands too much on our design decisions for this add-on then we may suggest you develop your pull request into a different add-on for EE.
You may find our post on contributing to open source software helpful.
Event Espresso is currently in the early stages of converting over to a "Domain Driven Design" / "Hexagonal Architecture" inspired approach to our application design and file structure, which organizes our code into several layers. We have refactored the file structure for our Add-on Starter Template to reflect this.
The following main layers / folders are typically used:
| Layer | Description |
|---|---|
| Domain | All of the business logic pertaining to what the add-on actually does. So the domain layer for a coupon application would contain all of the logic specific to defining coupons and what they do. |
| Application | Generic functionality that coordinates the actions to be performed on the domain. Basically the logic for connecting things together. |
| Infrastructure | Logic that connects the application directly to the server and/or outside world, such as databases, email services, external APIs, etc |
| User Interface | The UI layer displays information to the user and receives their input for use by the Application layer |
As well, more advanced add-ons may also utilize the following layers:
| Layer | Description |
|---|---|
| API | for processing requests via the Event Espresso REST API |
| CLI | for processing requests via the command line interface |
| Acceptance Tests | for running tests via Codeception |
| Tests | for running unit tests via PhpUnit |