The past couple weeks have been spent creating options pages for my own plugin. It is time to go back and make sure I have documented, organized, and generally cleaned up some code. It also is becoming necessary to store options in the database instead of hardcoding so that certain values can be easily updated in the future without having to scan multiple files for changes. Storing such data as variables allows much more flexibility.
I know have option pages for:
Basic Options
- Test the Scheduler
- Run the Scheduler
- List number of members in each level, especially highlighting users who have not logged in.
Dress Codes
- Dress code variables for student jobs, performances, and ensembles.
- The ensemble dress codes are unused now but I decided to add them now for future use.
Variables
- Email addresses; Music Admin.
- Tuition: SCF as well as comparison universities
- Emails: Subjects, html code for messages.
- Dates: Annual student expiration date as well as options for all dates throughout the year that are loaded into a php object when needed for manipulation on the webpages.
- Tickets and Prices: Defaults for both ticket prices and information on availability as well as the link to tickets.
- Links: Links to the college website, the music program site. More can be added as needed.
Objects These are all php objects used throughout the site to access commonly used properties.
- scf_music_department
- scf_departments
- scf_ensembles
- scf_instruments
- scf_subjects
CSS
Styling descriptions that are used throughout the site. Eventually I hope to replace all CSS with SCSS, which allows variables to be used in CSS.
- Headings
- Colors
- HR’s
- Shadows
- Text
Code Changes
These are very important. I have tried to NOT make any changes to hard-coded files used in plugins, but in a few cases I could not find an alternative. These changes are documented here so if updates break these changes I can re-implement them if necessary.
Data Checks
These are various functions to run on the database to search for possible errors that could cause problems. Each time I suspect or discover an error in a user’s data, I create a new function to search for that particular error across the enter database. These functions should prove invaluable in the future for tracking down possible errors, though ironically when I created these functions it is usually because I have found and solved the error, probably alleviating any future need for them!
- Clean up old PMPRO Users
- Check incomplete users. Checks for all sorts of user-related data and returns possible problems with a priority of low, med, or high. High level warnings have been given individual functions that can be run via ajax to fix the error in the database.
- Check music students for expiration error. Finds any students who have registered who were not set to expire at the end of the school year.
