| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does changes quite a bit of how things work under the hood.
It changes the filter settings from using POST to using query args in a
GET request instead.
This has some challenges:
1. The query args from the form will overwrite any query args in the
original URL, so we have to keep the query args that was passed in as
hidden fields in the form.
2. Since we try to keep the passed in query args, we need to filter out
the query args that we expect to set in the form, otherwise query
args that are dropped by the form will still be present as hidden
args.
Not too happy about how this works tbh, but at least it seems to work
reasonably well for now.
I've also renamed the args set by the form to make the URL a bit nicer,
i.e "city" instead of "selectcity" etc for the query arg keys.
I've also refactored quite a bit to make the code more manageable. Like
using the view helper to create the month selector, so it's consistent
with the others, and remembers it's selection. (I also simplified it to
simply list the months from jan to dec, instead of starting at the
current month. If it's important to keep the old behaviour I'll change
it back.)
There's a few problems still with this implementation.
1. It only works in the admin-section for now. Not sure why. Probably
because shortcodes...
2. In the admin section it gains the `cid` and `pid` query args that
should not be there. Not sure why.
3. If we change the filters while being on a page larger than the total
number of pages after the filter change, we stay on the page even if
it's not a valid page after the filter change. This should be trivial
to fix.
|
|
|
|
|
|
|
|
| |
The main render function was getting too large and difficult to work
with. Splitting it up a little to make it more manageable.
Also fix styling to make the pagination links fall on one line a bit
nicer.
|
|
|
|
|
|
|
| |
There's potential vulnerabilities here still, and I'm unsure if
get_permalink() is entirely safe to use in this context. Seems to do the
right thing, but the docs for the function indicates it has some edge
cases.
|
| |
|
| |
|
|
|
|
| |
added pagination to concert list
|
| |
|
| |
|
|
|
|
| |
Added a paragraph to have a bit of space under filters
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There's a bit of setup to make this work as it should, we need to ensure
that the current user and current screen is set to proper values so that
the WordPress api's `is_admin()` and `current_user_can()` work as they
should.
This first test just tests that all the expected forms are being
rendered for the admin user accessing the table through the site admin
interface.
|
| |
|
| |
|
|
|
|
| |
Added mailing for when concert status changes. Not sure how to get line break in text mails AND concert status as text
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
added class for City dropdown form
|
|/ |
|
| |
|
|
|
|
| |
Re-idented the file
|
|
|
|
| |
plugin
|
|
|
|
| |
with city
|
| |
|
|\ |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
AdminPage now references the database only through the Concert (and
Venue) models.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Clicking the buttons don't work quite yet.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of directly accessing the database with a custom query, we now
just use the Concert::find_concerts method to fetch the concerts that
are to be displayed.
This became much easier now that we don't rely on the extra concertlogs
table.
There's still stuff missing to be functionally equivalent to the old
code, but this should be a lot easier to get in place now.
|
| |
|
| |
|
| |
|
|
|
|
| |
This must have been forgotten in the previous commit.
|
| |
|