I will try to answer my best:
1) Event creation page
The difficulty will depend on how much you plan on removing from the events.
To help you better, it would be good to know what exactly you plan on removing.
Removing single field information (such as the event type for instance) should be quite easy.
The hardest part would be removing the “spots” from the events since it is implied in the price computation and allow quite complex possibilities. I tried to make clear workflows and break them in small steps so that modification should be easier.
In all cases I think the best way is to have a systematic approach: for each field you want to remove, first check everywhere it is used, be sure to understand their role and then make changes accordingly.
Please also note that you might have to perform similar changes in the registration page (which actually follows similar steps)
2) Applicant limit
You can implement this feature by simply adding a new field to the “event” data structure storing the applicants limit. You will of course also have to modify the event creation page to allow event organizers to input this number. This is very similar to the approximative number of applicants field that already exists.
Each event has a “Closed” boolean field that prevents any further registration. Currently events are automatically closed when the registration deadline is over. Closing an event and notifying all pending registrants of the event closure is actually done done by simply scheduling the “auto_close_event” API workflow of my template (actually there are several useful API workflows such as this one). Thus you will only have to add a button calling this workflow or a similar one in order to allow the organizer to close the event. Only display this button (by adding a condition to it) when the number of accepted registration has reached your limit. For safety reasons, be sure to also only allow the button’s workflow when this same condition ahs been reached (hiding the button is client-side protection, and putting a condition on the workflow is server-side protection, and thus better).
3) Working with my template
I suggest you the following:
- Each time you want to deeply modify a specific page (such as the event creation page), first duplicate this page and keep the copy as a reference. Then modify the original page, not the copy, according to your needs. Don’t do the opposite since other pages might point to this page and thus you will not have to modify them as well. When you are done you will just have to delete the copied page.
- If you plan on modifying the data structure, be sure to use the search tools of Bubble before deleting any field. This way you will be able to look where this field is used and make changes before actually deleting the field
- Get familiar with Bubble first. This is a complex app and I believe you will require to have good Bubble knowledge to fully understand it (be sure to look at API workflows and data privacy rules).
Another way of working with this template is to only use it as teaching material and look at it to find how to implement specific features. I believe you can use copy/paste to clone content from one app to another (but workflows and data structure won’t be copied).
I hope this will help you!