| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
added class for City dropdown form
|
| |
|
|
|
|
| |
Re-idented the file
|
| |
|
|
|
|
| |
plugin
|
|
|
|
| |
with city
|
|\
| |
| |
| | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| | |
|
| | |
|
|/
|
|
| |
This commit is useless
|
|\ |
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
# Conflicts:
# includes/admin/views/giglog_admin_page.php
|
| | | |
|
| | |
| | |
| | |
| | | |
Added CSS and extra fromatting to table
|
| | |
| | |
| | |
| | | |
Added order by concert date in concert list
|
| |\ \
| | | |
| | | |
| | | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| |\ \ \
| | | | |
| | | | |
| | | | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
https://code.volse.net/wordpress/plugins/gigologadmin.git into andreaschanges
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
local hashkeys?
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |_|_|_|_|_|_|/
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Since the plugin only should load on the admin side, set the WP_ADMIN
constant before loading it in the tests.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It's not required since the id is in the concerts table too. That's what
links them together.
|
| |_|_|_|_|_|/
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently the AdminPage is still responsible for updating changes to any
of the concerts, but I'd like to get that into their respective classes
too. That way the AdminPage will just be a simple class to handle the
layout of the page, while all the specific functionality is in their
own classes.
This is also the first step to be able to reuse the concerts table on
the public end of the site.
|
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We originally had a more specified query, but simplified it to:
SELECT * FROM wpg_concerts LEFT JOIN wpg_venues ON ...;
But since both the concerts table and the venues table has a column id,
the concert id would be overwritten with the venue id. MySQL/MariaDB
does not allow columns with the same name in multiple tables when using
unqualified column names in the query.
So we need to be more explicit again.
I was hoping that the following would work:
SELECT wpg_concerts.*, wpg_venues.* FROM .... ;
I think MySQL/MariaDB would handle that, but now since php turns the
result into an array, where each key must be unique, this again
overwrites the concert id with the venue id.
So thus a more verbose specification of the columns was necessary.
|
| | | | | | |
|
| |_|_|_|/
|/| | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These tables are no longer being used, so let's remove them and the code
to add them.
|
| | | | |
| | | | |
| | | | |
| | | | | |
These are no longer in use, and have been replaced by the admin screens.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
AdminPage now references the database only through the Concert (and
Venue) models.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
To keep track of creation and modification times for each record.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
No need to deactivate/activate plugin to get the right version of the
tables.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As a user can only be assigned to one role at the time, we remove the
current user from any role that they may have when clearing the
assignment.
|
| | | | |
| | | | |
| | | | |
| | | | | |
It did not return any users, but a form so name it for what it does.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The original name did not make much sense. The function didn't return a
user, but a dropdown list of users, where the user currently holding the
given role for the given concert was preselected in the list.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Replace the table with hardcoded strings in the AdminPage class. This
makes it a pure presentation issue, while the statuses themselves are
just mnemonics.
There's one smell here, and that is that the status values and their
textual representation is split across two modules. (Values in Concert,
and textual representation in AdminPage.) This should probably be
addressed later by refactoring both into a separate AccredStatus class
or something.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will trip up any existing records in the db, but that should not
matter, since we're changing how this entire stuff works now.
|