A request web app?

[Nakatomi]

The other week I put request slips into a venue where I'm pretty much hidden away. They were an incredible success - I was inundated with bits of paper & I felt the element of interaction at the venue went up a good few notches. However, little bits of paper are annoying & handwriting can be hard to read.

I originally considered making a device app for clients/guests to make requests, but I only have Android devices at home & any app thing would need a web backend anyway so I've boshed a thing together on my own Virtual Private Server using PHP,MySQL & Ajax.

How does it work? Well, ahead of the event or on the day the app administrator (i.e. me) logs in & creates an event 'key'. This key is (at the moment) only valid on one day but can roll over by a globally configurable amount. The URL & key need to be displayed somewhere at the venue for this to work of course!

The admin can see & edit all requests made by clients for any of the event keys previously generated. They can be marked as 'played', or 'will play' ('played' can be shown on the customer facing side) - 'will play' is for the DJ's own reference).

What does the client see?

The customer facing end is a basic login page:

17098
then a list of any requests made so far, along with buttons to add a new request or log out. :


17102

Adding a request, the end user sees this:

17099

And this, if their submission is successful:

17100

The showing of existing requests is set by the administrator & is optional. In the case of the list not being shown, the user is only shown a count of requests made so far.


I've trapped everything out that I can think of.. xss, mysql injection & HTML code insertion.. and all user input on the customer facing side is error checked (certain fields can't be blank or too long). I've also included flooding protection (which of course is configurable):
17101

CSS styling is still a bit up in the air & it looks best on mobile devices.. apart from the admin end which at the moment is suited to bigger screens only.

17103

It can't give the end user any choices based upon an existing music database - I don't want that available on the night.. crazy requests can be bad enough without people seeing what I haven't got around to pruning yet.

The flooding protection is currently based on the user's IP address which has its limitations of course, but it's generally the case that a device connected to a venue's wifi or a mobile network will have a unique address for a while at least.

Yes, I'd much rather people came to see me in person (in general) but I see this as just another interactivity ice breaker.

Obviously the proof of the pudding will be in the eating.. it's definitely possible that it could be abused, but this like any other system of requests still doesn't come with any guarantees.

Any thoughts (other than "it's a bit green".. that's not set in stone) ? Oh, and apart from the fact it needs to feature the darn annoying EU legislated cookie warning (GRRRRR).

[Shaun]

Over the years here on the forum the subject of requests slips and the likes have stirred up a mixed bag of opinions. Some hate the idea of using request slips and others embrace it. I've used professionally printed request cards for over nearly a decade and they've been a huge success for me and the way I work. I really like what you've come up with. It might not be to everyone's tastes but I'm sure the younger generation will love it. :beer1:

[Excalibur]

Over the years here on the forum the subject of requests slips and the likes have stirred up a mixed bag of opinions. Some hate the idea of using request slips and others embrace it. I've used professionally printed request cards for over nearly a decade and they've been a huge success for me and the way I work.

I'm a fan of request slips. I don't often use them, and they're not professionally printed, but at the right occasions, they're invaluable.


I really like what you've come up with. It might not be to everyone's tastes but I'm sure the younger generation will love it. :beer1:

Certain of the older generation love it as well. Don't understand a word of the explanation, still think it's powerful voodoo, but love it. Well done that man.

[DJ Jules]

I'm a big fan of request slips and they work well for me. My only concern with moving them online is that where people don't have to face you (i.e. physically hand you their request) you'll find they get a bit silly with their requests. I've played with txt requests before and they've almost always been nonsense.

It's a good effort though. It's made me think about tweaking the pre-event request system I have to work for "on the night" requests as well.

Julian

[Andy P]

love that app - if you get it working for multi user would love to give it a run

[Shakermaker Promotions]

Firstly, well done for coming up with something like this. It's a decent idea and I'm sure a lot of people will like it.
The thing with me is that I like interraction with the guests. I used request slips for a long time on and off and they work for me but I actually like to talk to people.
The way technology has moved on over the last few years is brilliant in some respects but also a pain in others.
I did a function the other week and although lots of people were on the dance floor, I could see lots of the younger crowd sitting there not even communicating with the people on their table because they were on their mobile phones.

I've had people stroll over to me before in both a club / pub environment and also at a private function thrusting their phone in my face and not saying a word. They've just expected me to look at the screen and have then said "Have you got this?". Unbelievably on other occasions they have actually taken their time to write a text and hold it up and not said a word at all and I can remember a particular occasion at a wedding I was doing where a guest came over to me and said "Excuse me" and then actually stood there writing a text message to me and then showed me it. Something along the lines of "Excellent night so far. Do you have **********?"
I couldn't believe it and to be honest, all of the above examples I have mentioned come across as rude and ignorant to me but I guess it's the way things have moved on.

Yes, I think this app would work in certain scenarios and yes, it's always good to gauge what the punters are in to and yes, it's another service but it appears that the days of actually going up to the DJ and speaking to them are on their way out. It's a shame. I like to be very approachable and I think it's more personal when you can interract with the audience rather than standing there checking out the requests that are coming in.

Obviously you'll give it a trial at some point and I'd be interested to hear the results. I may well be totally behind the times though and this could be a really good thing?
Like I said though, well done.

[Marc J]

The flooding protection is currently based on the user's IP address which has its limitations of course, but it's generally the case that a device connected to a venue's wifi or a mobile network will have a unique address for a while at least.

The IP you'll get is the public (WAN) IP, which for any devices connected to the venue's WiFi will probably all be the same, so your flood protection will get hit pretty fast I'd imagine if that's what it's checking.


Oh, and apart from the fact it needs to feature the darn annoying EU legislated cookie warning (GRRRRR).
I really wouldn't bother for this. The previous champions of this (https://ico.org.uk/) have even stopped bothering to take their own earlier advice. See The stupid cookie law is dead at last (http://silktide.com/the-stupid-cookie-law-is-dead-at-last/).

Good work on the request thing, though....will you be sharing or offering it for sale to others?

[Nakatomi]

First of all, I must stress that this isn't intended to replace human input. I much prefer talking to guests in person but there are times, for whatever reason (maybe they think we bite or something) we can tell we've not hit the spot yet by reading the room. Maybe the app will help, maybe not.... That remains to be seen.

As far as multi user cases go, I only intended this web app to be for a single user, i.e. me but I'll look at extending it to be able to cover a multi-op case too.

In any event, I wasn't planning on hosting the service for anybody else.. It'd be something another company (i.e. You) would host on their own site. I might look at hosting it as a service to others if there's enough interest.

It still needs a little work since I've found that the exploit protection is getting rid of punctuation... The flood protection can easily be changed to generate a unique code per user device, which I'd already considered doing anyway.

As it happens back at the venue where I'm difficult to access again this Saturday so all being well I'll give it a go then, alongside the more traditional slips.

Lastly, thanks for all your input so far, I really appreciate it :-)

[Nakatomi]

The IP you'll get is the public (WAN) IP, which for any devices connected to the venue's WiFi will probably all be the same, so your flood protection will get hit pretty fast I'd imagine if that's what it's checking.



Doh! I dunno how I didn't realise that in the first place. Thanks for pointing out what should have been obvious.


I really wouldn't bother for this. The previous champions of this (https://ico.org.uk/) have even stopped bothering to take their own earlier advice. See The stupid cookie law is dead at last (http://silktide.com/the-stupid-cookie-law-is-dead-at-last/).

Good work on the request thing, though....will you be sharing or offering it for sale to others?
I HATE the cookie warning scourge. As far as privacy in the net goes, cookie storage should among the least of any users worries. In the past I've operated on the principle that I'd do nothing until I get told off ;-)

I'll make some more changes this week & see how it performs at the weekend in a real life situation, maybe using a QR code on actual request slips so people with smart devices can go straight to it (no need to enter any code on the users part then).

As for sharing/selling, when it's ready for prime time use I'll think about some scenarios.

[Andy P]

Cool, will keep an eye on progress - might have a go myself.

[Andy P]

also how are you getting it on the market place and is it for apple too

[Nakatomi]

That's just it - it's a web app, not an 'app app', so the user just points their device browser at the site. No installation necessary.. I mean who'd want to install an app just to make requests at one event? ;-)

There's that aspect, and it makes life way easier for me:

No need for me to own an iDevice, no need to try & get it past Apple's app police.. no developer licence complications...
No need to test it on multiple Android versions...

This way I only need to develop one thing, as opposed to three :-) (Four if anybody actually has a Windows phone!).. oh wait then there are Blackberry users to consider (or not).. heh.

So yeah.. it's just a bunch of web pages. I'll have something people here can try for themselves soon.

[Andy P]

cool - got me confused there with the word app. What do you code in?

[Jim - Scotland's Party DJ]

That looks brilliant.

Would definitely be interested in looking into using it if you were aiming to make it commercially available.

My only thought though (and I don't really know the workings of the tech side of it) do you need an internet connection on the night for it to work or do the requests come to you via texts or something?

[Nakatomi]

cool - got me confused there with the word app. What do you code in?
It's coded in php on the server side & uses Ajax through Javascript & jquery. The database side is mySQL.

My last job involved supporting a monster of a web app which administered fleets of mobile & fixed CCTV installations.

I really only set out to see if I could do it rather than have anything commercial in mind.. It's my first foray into making anything web facing from scratch.

My other sideline is hosting, developing and troubleshooting a Prestashop website for a friend of my sister inlaw which sells lingerie & er.. Adult items. It's all good for the CV :-)

[Nakatomi]

That looks brilliant.

Would definitely be interested in looking into using it if you were aiming to make it commercially available.

My only thought though (and I don't really know the workings of the tech side of it) do you need an internet connection on the night for it to work or do the requests come to you via texts or something?

It needs an internet connection to work, though I can easily make the admin side more mobile friendly. Sending text messages from a server would be messy.

[Andy P]

Its cool - all the commercial ones are silly prices for what they do. You can get Content Unlimited for VDJ for the same price as a request app :mad:

- - - Updated - - -

PS i see your local to me - what comapny do you run?

[Nakatomi]

I'll try to explain how it works in simple terms.

The user, ie the person wanting to make a request, points their tablet or phone at the request website. They log in using a code unique to the event (supplied by the DJ, maybe printed out & displayed somewhere). They are then presented with a page where they can see existing requests and add new requests.

The DJ logs in on a completely separate part of the site, can see the list of requests and is able to edit them, mark them 'will play' for their own reference, and 'played', again for their own reference.

The DJ can also delete requests (maybe not a very friendly idea) and of course can add, amend or delete the codes which site users can log in with.

I'm thinking about adding a 'print event sheet' feature which would allow the admin to print a page featuring the web address, the event code and a qr code. If you don't know what a qr code is, it's an image made of dots that you can scan with a smartphone or tablet, which can take a user to a web address with no typing involved.

[Nakatomi]

Its cool - all the commercial ones are silly prices for what they do. You can get Content Unlimited for VDJ for the same price as a request app :mad:

- - - Updated - - -

PS i see your local to me - what comapny do you run?

I don't. Yet!

I came back to the game last year doing walk-in jobs for a guy I work with in my day job. The plan is to spend what's left of the money from that on my own rig. I'm getting there, slowly. He was due to quit at the end of last year & offered me the chance to take up a 'lucrative' residency, but wanted paid for it and I'd still have to buy gear. Add to that the venue isn't all that, doesn't offer any kind of client contact, doesn't know what's coming up from one week to the next... Meh... Might as well go it alone after all.

[ukpartydj]

I've just been coding a simple request form for use before the event. It'd be their own personalised database which they can invite friends and family to look at / make additional requests.
I know some people already have these - just want to give it a go making one myself so I can learn something from it!

Unfortunately I wouldn't really go for this web app idea though, there is a bit of a buzz about asking the DJ for a request in person / handing them a request slip - it may still be there with the app (hard to tell without trying) but I feel it wouldn't feel quite a fun!

[Marc J]

Sending text messages from a server would be messy.

Not really, it's as simple as sending an email. I do it for ecommerce clients to get copies of orders via SMS, using http://www.clickatell.com/.

If I were you, I'd use Bootstrap for the front-end (and also maybe the back-end). Nice and simple :)

[Nakatomi]

I think sending SMS messages out might kind of defeat the object of having a web app.

A good idea to use bootstrap though... An easy way to make any site 'responsive'. And just one more thing to learn! Heh

[Marc J]

A good idea to use bootstrap though... An easy way to make any site 'responsive'. And just one more thing to learn! Heh

It's really very easy, but I'd be happy to give the front-end an overhaul using bootstrap for you if you wanted a colaborator...

[Nakatomi]

Right then. A bit of code fettling has changed the flood detection to make the system generate a 'unique' number per client when they log in to use as an identifier. It won't be infallible but it's near enough for the application.

Tonight I plan to start work on a settings page so all the configuration is stored in the database rather than a config file. After that, a multi user scheme will come along.

I'm considering options to make this available to others & basically they boil down to:

1. Host it for people, make it customisable & charge a small subscription. The downside with this would be the support & admin burden.

2. Sell it as a package like a zip file & expect competent people to add it to their own site. The downside here is that people can just give copies of the code away to others. There are ways to try to prevent it, but I have little experience in doing that.

3. Release it as open source software that anybody can use for free & can contribute to.

Right now I'm leaning towards the latter. It started out as a bit of fun hacking.. I have a conscience & user support can frankly be a nightmare no amount of money can compensate for. My last job taught me that!

[DJ Jules]

User support can frankly be a nightmare no amount of money can compensate for. My last job taught me that!

:agree:

Many years ago I released a 100% self service website system to a specific industry and the admin and support side completely overwhelmed me. It should have been a 100% self service CMS, but I continuously had customers emailing me asking me to change text and add or remove photos - I ended up offering two packages, site alone and site & support with the second priced considerably higher. People finally got the hint that they either had to click a few buttons, or pay me to click the buttons, but setting out the two packages up front allowed me to tell people to pay up for support or go away :D

Julian

[Marc J]

I'm considering options to make this available to others & basically they boil down to:

1. Host it for people, make it customisable & charge a small subscription. The downside with this would be the support & admin burden.

2. Sell it as a package like a zip file & expect competent people to add it to their own site. The downside here is that people can just give copies of the code away to others. There are ways to try to prevent it, but I have little experience in doing that.

3. Release it as open source software that anybody can use for free & can contribute to.

I like option 3 :p

I'll gladly contribute anything I can, time permitting.

[Nakatomi]

I like option 3 :p

I'll gladly contribute anything I can, time permitting.

Yeah going the open source way will be for the best I reckon. I've already got one part time job, no wait make that TWO... and another would just be silly.

I'll keep chugging away getting this into a releasable state & start a project on github :-)

[Andy P]

3. Release it as open source software that anybody can use for free & can contribute to.

Right now I'm leaning towards the latter. It started out as a bit of fun hacking.. I have a conscience & user support can frankly be a nightmare no amount of money can compensate for. My last job taught me that!

Probably the most noble route if your doing it as a fun project. People warm to this and often pay

[DazzyD]

... I'd be happy to give the front-end an overhaul using bootstrap for you if you wanted a colaborator...


...
I'll gladly contribute anything I can, time permitting.

I'm not sure these hints are being taken! :eek:

[Nakatomi]

I'm not sure these hints are being taken! :eek:

Ah but they are & they're appreciated! I just want to get the code into a state where I'd be comfortable with somebody else seeing it. Maybe I should've waited before shouting about it from the roof tops..

Either way it won't be long before I'm ready to accept testers & code contributors

[Nakatomi]

Just a progress update to say that there really hasn't been much progress made lately..

I've just been refactoring code to change the database method used & ran into some unexpected issues - which I managed to fix tonight so I can proceed with er.. whatever I planned to do before I got sidetracked.

[Nakatomi]

While I was out on Saturday I thought of a great feature to have in the app but didn't make a note of it & now can't remember. But... When I make this multi user I've thought of another thing just now.

Settable in the preferences page, a 'your DJ is...' Section, maybe with a photo. I think it'd be nice to have so I'll add it :-)

Fyi the next feature, which could be finished tonight will be the ability to generate a QR code guests can use to log in without typing in the event key :-D

[Marc J]

I should have time to look at it soon, once you've got all the features you want in it I'll go in give it a makeover using bootstrap which should also make adding things much easier on the front-end...

One feature I think would be good would be the ability for the admin to manually block a user - someone who's not hitting the flood limiter but sending ridiculous requests or is being abusive, for example...

[Nakatomi]

I should have time to look at it soon, once you've got all the features you want in it I'll go in give it a makeover using bootstrap which should also make adding things much easier on the front-end...

One feature I think would be good would be the ability for the admin to manually block a user - someone who's not hitting the flood limiter but sending ridiculous requests or is being abusive, for example...

Ah now there's a thing I initially considered but dismissed. Consider it UN-dismissed! I dunno, me & my faith in human nature ;-)

I'll have to re-jig the cookie code but it should be possible, at least at a client level. If they switch to a different device or clear their cookies they'll just get in again.

Aha! Now that's reminded me of the other idea I had. Customisable text for the onscreen messages!

All this feature creep.. Is fun, no?

See also, ERROR: Your message to the DJ did not include the word 'please' :-D

[Nakatomi]

Regarding blocking..

I'm thinking just a plain 'sorry, you cannot make any more requests at this time' kind of message.

Which brings another idea: a per user request limit. Configurable, of course

[Marc J]

Which brings another idea: a per user request limit. Configurable, of course

I agree...the more configurable the better...

[Nakatomi]

Update:

I just got banning working ( by hard setting it in the database for now). I figured it's a more urgent feature than multi-user right now.

I was originally only storing the 'unique' id generated at login in a session variable. This had a drawback that if the user logged out, the session was destroyed by the server -they could log straight in again & get a new 'unique' id. Not now. Now it stores a cookie & creates an entry in a new table (requestusers)... This is checked when a user submits a request & it decides whether to allow it or not based on the 'banned' column in the requestusers table :)

Next up, wiring that up in the admin page & add the ability to delete all requests by that user in one swipe.. and housekeeping functions to delete old entries in the requestusers table.

All changes to date have been pushed up to the github project at http://www.github.com/jhornsby/djrequestapp

[Nakatomi]

Another update:

Now there's a max requests setting in the event keys table which means you can set a limit of the number of requests a user can make. I'll likely add another max setting to be able to set the total number of requests allowed per event

17114

Also, users can be banned & their requests deleted at the click of a mouse :D

17115

Oh yeah, and the users admin page (2nd screenshot) will likely be going away as it'd be more convenient to have the 'Ban' & 'delete all requests by this user' buttons in the main request list

[Nakatomi]

Another progress update:

I've not got much done this week, what with the 2 wedding discos & a trip away to deal with but tonight I got some more done towards making the app multi-user & have done some general tidying up & a couple of bug fixes.

The admin side of the app is going to need a separate menu file.. there are now a few pages & putting the links to all of them on every page is gonna get to be a pig eventually.

[Nakatomi]

Progress update.. adding multi user stuff is coming along, but slowly. This is one of the problems when you have to change a database schema on the fly as you come up with new features :)

[Marc J]

Great work so far, Justin....I know there aren't many replies to this thread but I for one am keeping a close eye on it, and I'm sure there are others!

[Nakatomi]

Thanks Marc. The tricky bits of the multi user stuff are just about done I think.

I need to take a good run at it at some point rather than chipping away as & when. Heh.

[funktions]

Great work so far, Justin....I know there aren't many replies to this thread but I for one am keeping a close eye on it, and I'm sure there are others!

same here, tried it once on android and got totally confused.. so I know there are many better people at doing it than me lol

[Andy P]

is there a link to a test/working version or am i missing something

[Nakatomi]

Because of the multi user stuff I'm working on it's not ready for testing by you lot yet.

I know I said 'soon' about 3 pages ago but I've had a lot on.

I'll probably have something you can try out by the weekend.

For what it's worth the link I posted is to where the raw code for the project is hosted & isn't a 'live' app :)

[Nakatomi]

Right then!

http://www.mrdeejay.co.uk/requests is the place to go and act like a customer. A code you can use initially is mddf

See how that works for you.

For the admin side, I've set up a level 2 user (can create events, see & edit requests, remove requests, ban users etc - everything bar administering admin level users infact) and you can log in here: http://www.mrdeejay.co.uk/requests/admin/ with the username test and the password mddfpassword.

That's just for now. I think there are still a few bugs I need to squish - but you shouldn't be able to see any of the stuff I'll be using tonight at the venue.

Page styling is all over the place, but I'm leaving it as it is til Marc's had a look at it. The user side looks 'acceptable' IMHO.. but again I'm not gonna bust any guts on that til Marc's played with it.

Try not to ask for new features - I've got a raft of them still to go in like being able to list requests already played separately to users, and being able to fully customise all the text users see in messages (for successful request submissions, saying they've posted another request too soon, and saying they can't make any more requests cos they've been BANNED.. etc).

Right now it's only suitable for one 'company' with a number of DJs.. I'm considering making it even more multi-user with 'groups' which won't exactly be much work apart from wrapping my brain around MySQL JOINs :D

Any questions, post em here. I've tried to keep it super simples cos not everyone has a brain the size of a planet like me (kidding, this is a bunch of hacks of tutorial code stuck together with gaffa tape). Maybe some terms in the app will be renamed, e.g. 'event keys' will become simply 'events'.. but those kind of things are mere tweaks.

Lastly, go canny with this please. It has error trapping & hack protection to a certain extent but I haven't fully tested that stuff yet. I'll set up a full test system on my server soon where you can really let rip with it.

[Shaun]

I know there aren't many replies to this thread but I for one am keeping a close eye on it, and I'm sure there are others!

I'm watching with great interest too. :)

[Marc J]

I created a new event, mddf2, and it wont print from admin and can't be logged in to by users....perhaps because it's only slightly different to mddf (maybe the operator you're using for the event key?).

Clicking on the User String link in admin gives 0 results, even though there obviously are (from the previous screen).

EDIT: Is what's on GitHub just now the same as this demo?

[Nakatomi]

Marc, no github is not synced up yet.

There was an event with key mddf2 already. I thought I'd made that column unique so there you go. I'll have to add error checking for that & change the DB schema a bit.

There's an issue with the DB query for the users list .. Should be a dead easy fix.

I'll get onto it tomorrow night. Tonight it'll be trashed, err I mean used by patrons at an 18th birthday party.

[Nakatomi]

By the way how did whoever it was manage to skip entering a title? That should be trapped. Hnmm.

[fullcontact68]

By the way how did whoever it was manage to skip entering a title? That should be trapped. Hnmm.

Might of been me. I love trying to rise to a challenge of breaking something :p

Tried htmldecoding entries which have been entered. <br> in this case.

I did notice that you truncate html entered into the message though.

[Nakatomi]

Might of been me. I love trying to rise to a challenge of breaking something :p

Tried htmldecoding entries which have been entered. <br> in this case.

I did notice that you truncate html entered into the message though.

Needs better trapping & reporting then. I'll get on that tomorrow.

It's annoying to have to do, because most users won't have a clue. I'd rather the chide be pretty much bomb proof though

[Nakatomi]

Tried it out last night. Birthday boy's mother thought it was amazing, but she shied away from asking for stuff she liked. I had a sum total of TWO requests using the app all night, all very polite, so nobody had to get banned.

I'll get onto the admin fixes at some point - I changed the method of keeping track of which admin is logged in & didn't convert the user (not admin user) stuff over to it. I'd pondered getting rid of that page anyway, but maybe it should stay after all.

[fullcontact68]

Needs better trapping & reporting then. I'll get on that tomorrow.

It's annoying to have to do, because most users won't have a clue. I'd rather the chide be pretty much bomb proof though

It's amazing what our testing department do to try and break my work :(


May be worth setting the maxlength attribute in your markup.

[Nakatomi]

Ok the user list bug is almost squished. I just need to add another bit of code to filter stuff for multiuser admins & that's just another 'if' with a WHERE clause tacked on.

That'll get sorted by tonight along with a schema change to make sure event keys can't be duplicated. Then possibly some more error catching to stop blank fields ending up in the requests.

I'll probably make the message field conditional too, so if it's blank it won't show. Or maybe make it hideable per event as well.

Any other ideas for improvements? Preferably ones that won't involve much work!

[Nakatomi]

It's amazing what our testing department do to try and break my work :(


May be worth setting the maxlength attribute in your markup.

Yeah good idea, that.,5 minute job too

[Nakatomi]

Right folks. Give that a go now. You should be able to see all the users wot generate requests for the mddf test account.

More fixes later.

Oh and Marc, github is up to speed now

[Marc J]

Clicking on user strings in admin still gives a "No records found<" error (for example http://www.mrdeejay.co.uk/requests/admin/user.php?user=5534f68eef05e)

[Nakatomi]

Ah. That's gonna need some gentle massaging. With a hammer. Or three.

[Nakatomi]

That took a few more hammers than I thought. Should work better now. Pushed the change up to git too, Marc.

[Marc J]

That took a few more hammers than I thought. Should work better now. Pushed the change up to git too, Marc.

Works for some, not for others - any with IP 86.128.198.176 (yours, I think) still show no results....

[Nakatomi]

Ah yeah. That'll be because the cookie on my laptop was still set from logging in on Monday for a different event so a new user wasn't created when I logged into the mddf event. An unusual case. The test user can't see user strings created by users logging in to events which aren't theirs. If they later log in for a different event.. Err... The cookie should expire between those things & a new user unique Id created. I'll look into why that didn't happen.

Not so much a bug but a corner case I hadn't foreseen. I'll give the user cookies a shorter life, that should do it.

I'm going to crack on with abstracting all the database stuff out into a function today to cut down on code duplication. It should also pave the way for object oriented practises later on too.

When that's done, work on customising output text can begin.

[Nakatomi]

Maybe I might look into only letting a user log into a number of different events before kicking them out.. It's not inconceivable that venue staff could use this to sway things in their direction. A guest might attend two events in a space of time at one venue, but more.... ?

Anyway, I added more trapping last night so that any escaped fields resulting in blank text prompt the user to try again. Getting to be quite a monster, this.

Btw I've gone with hidden elements for user messages. I dunno what bootstrap offers, but popups on mobile devices can be annoying

[Nakatomi]

Marc, I've put some changes in tonight which might prevent the same login cookie for multiple events thing becoming a problem.

I'm going to make the cookie expiration configurable too, maybe on a per-event level as well as globally.

Now, what else did I say I was going to do? Heh.

[fullcontact68]

Now, what else did I say I was going to do? Heh.


Err, was it custom skins to suit different events / venues / DJ's etc?

[Nakatomi]

Yeah that's still on my to do list but there's no point starting that until the front end is converted to bootstrap.

I've looked at abstracting all the database code & I'm now wondering if there's any point. I need to call this almost finished feature wise soon :lol:

Putting it in front of customers again on Saturday so if there's anything to report I'll post it here

[Marc J]

Until your finished, Justin, there isn't much point in me taking a look at the front-end makeover...so just let me know when you're backing off! ;)

[fullcontact68]

I've looked at abstracting all the database code & I'm now wondering if there's any point.

The only point of doing this is if you can make use of the same code again in other areas, if not, probably no point in doing so.

Unless you have time to burn that is. It's best practice to separate out your business layers, data layers etc.

[Nakatomi]

Until your finished, Justin, there isn't much point in me taking a look at the front-end makeover...so just let me know when you're backing off! ;)

I think I'm about done for now. The methods in place should be enough to go on with.

Regarding database abstraction I think the DB stuff isn't likely to be added to or changed much in the near future.

The changes still to do are mostly in the backend, but customisable text can be incorporated after the bootstrap conversion.

Skinning won't be too hard & I won't be after the layout being user defined, though I know there are loads of libraries around to make that easier.

I'll hack through the code in the next few days tidying things up, removing unused stuff, maybe refactoring one or 2 things. Oh and maybe write some documentation!

Oh yeah, I need to add some database error trapping before I do anything else. Pretty basic, but all the DB code just assumes it's set up properly at the mo.

[Nakatomi]

Okay. I've now made a duplicate system for y'all to test out to your heart's content.

You've all got full access.

Admin login is 'admin' and the password is 'mddpassword'

http://www.mrdeejay.co.uk/mddrequests

Have fun!

[surround sounds]

It says enter key code. What do I put there

[Nakatomi]

Whoops. Add the word admin to the URL, thus:


Www.necessary.co.uk/mddrequests/admin

[surround sounds]

Whoops. Add the word admin to the URL, thus:


Www.necessary.co.uk/mddrequests/admin

you mean this link

http://www.mrdeejay.co.uk/mddrequests/admin/

[Nakatomi]

you mean this link

http://www.mrdeejay.co.uk/mddrequests/admin/

Yeah. Stupid autobongle on my phone :D

[Nakatomi]

17139

As you can see, there's a bug - the userid string isn't being generated for auto-logins using the QR code - easily sorted. BUT... a successful application of the app I think. It took a while for requests to come in & they were sparse, and nobody bothered to come up & ask for anything (wah - Mr Lonely DJ)..

Funny, this one - I'd have expected there would've been more takeup at the 18th I did last Monday, but they preferred to see me in person. This bunch were generally a fair bit older than the 18th crowd & used the app more.

Is it ready for prime-time? Almost.

[Excalibur]

I've had a play with it. I made requests. To make requests from other devices, I had to get a new event key from the site, then I could make requests from tablet and phone, no problem. Was this the way to do it? :confused::confused:

In many regards, it's brilliant. In other ways, it baffles me. Where can I get djrequests for Dummies? :daft:

[Nakatomi]

Hi Peter.

The event keys are set to expire by default (will expire), so if you try to use one after its active date it won't allow a login, which I suspect is why you had to create new keys for it to work.

I've started writing a manual for the app but haven't got far yet.

Sounds like you're getting the hang of it already though
:)

I think I'll add the ability for an event key to be active between two dates as well - this is going to have uses beyond 'on the night'.

[Excalibur]

Hi Peter.

The event keys are set to expire by default (will expire), so if you try to use one after its active date it won't allow a login, which I suspect is why you had to create new keys for it to work.



Well yes, but I reckon fifteen minutes is a bit quick! :D:D I had got it working fine on the desktop PC, but the key was invalid on the two portable devices, thus why I got a new one. I presume that at a gig, I have to give punters the event key, haven't I ? How do I best do that?

I'm impressed that I managed to get it to work at all, well done Justin. If I can do it, anyone can.

[Nakatomi]

15 minutes? Yikes that sounds very short. I've not had any issues like that at all. I'll take a peek at the mddrequests section in a bit.

Now then.. how to get the magic codes to the lovely user. That's fairly easy. On the 'print' page of the 'manage events' (as it's now called) section it will output a QR code. A QR code is a 2 dimensional barcode, into which can be encoded text like a web address. The app automagically generates an address which will log in a user who scans it on their phone or tablet. That page looks like a badger's bum right now, so what I've been doing is making a nice doc like this:

17140

which I print & distribute around the tables & bar area before the guests arrive. Simply copy the QR code image from the right page, plop it into a doc & print.

Alternatively, just give out slips of paper with the request app URL and write out the code for them to log in manually.

I was watching people using it last night from my lofty post as they scanned the flyers directly with their phones. The asst manager thinks it's amazing, but I keep telling him I'd much prefer to be downstairs among the guests. Funny, he says. None of the other DJs who go in there say that. Yeah, they wouldn't, the door locking crowd ignorers... meh.

One thing to note about the QR code generation though.. in the settings page, the 'base URL' section must be filled in correctly otherwise the QR code image won't contain the right web address to take the end users to. E.g. if the site is www.mrdeejay.co.uk and the requests app is at '/mddrequests/' one would enter http://www.mrdeejay.co.uk/mddrequests/ in that field.

[Nakatomi]

Peter, I can only see one event in the database in the mddrequests app section. If you leave any you have trouble with during testing I might be able to get a handle on what's going wrong :)

[Nakatomi]

I've started putting error trapping into the back end now, so if an admin tries to change something & finds they can't, the app will tell them why.

[Nakatomi]

Feature update:

Request messages can now be configured to show or not.

I've started work on customising the text shown to users too. This can be done on a per admin level, so each admin can have their own custom text shown to end users.

There's quite a bit more code in this thing than when I started. Heh.

[Andy P]

Personal logos mate

[Nakatomi]

Personal logos mate

Well yes. That and custom colours & fonts. All on their way too.I don't have to wait til Marc converts anything to bootstrap so that'll be next I suppose.

There's still some work to be done adding more text customisation, and I could do with getting password resetting working too first.

I'm beginning to wish I was getting paid for all this :lol:

[Marc J]

Rather than go through all the hassle of doing an image upload facility and the security issues that brings, why not just have a logo.png file in the root which is what the installation looks for?

Whoever uses this will be uploading the whole thing, anyway, and so changing that image will be easy enough.

[Nakatomi]

Rather than go through all the hassle of doing an image upload facility and the security issues that brings, why not just have a logo.png file in the root which is what the installation looks for?

Whoever uses this will be uploading the whole thing, anyway, and so changing that image will be easy enough.

With you on that Marc, but I was under the impression that the point of multi user was for multiple disco companies under one roof, hence the plan of mine to have groups of users at some point.

I'm all for less work though. Infact, why even bother with multi user? This app already does everything I want :) The styling needs some tlc, but that's easy peasy compared to what I've accomplished so far.

I think the user groups etc was still keeping an eye towards this being a service you could host for others but I'm cold on that idea now anyway. "Can you just....?". Heh

[funktions]

I know this might be a silly question, but what would be needed to run this as a local setup ? rather than actually having to access the "real" internet and relying on the fact the venue has wifi. im impressed with what you have done though...

[Nakatomi]

I know this might be a silly question, but what would be needed to run this as a local setup ? rather than actually having to access the "real" internet and relying on the fact the venue has wifi. im impressed with what you have done though...

Nooo, not a silly question at all. You'd only need a spare laptop or other small computer to run a server 'stack' (eg Apache, MySQL & PHP) on Windows or Linux.. and you could even set up your own 'ad hoc' wifi network so you wouldn't have to rely on the venue having its own wifi. You could run the web app server in a virtual machine, but I still wouldn't dream of putting it on my DJing machine.

You could even run this on a Raspberry Pi (http://www.raspberrypi.org) :D

I'm running this on a LAMP stacked server (that's Linux, Apache, MySQL & PHP), but you could just as easily run it on a WAMP server (that's Windows, Apache, MySQL & PHP) - or indeed any web server platform so long as it's got MySQL database & PHP5 support. FYI Apache is the name of the web server program, MySQL is the database program & PHP is a programming language.

[Nakatomi]

Hmmm. Pootling around in the database I've noticed something from last Saturday. 'Natalie', the bride, asked for 'sweet child of mine' to be played much earlier in the night than I originally thought. For some reason her first request ended up in the database without an event key & didn't show up in the list.

Another request also didn't show up.. from 'Michelle' for 'Never be alone' by Nickelback. I'm puzzled as to how these 2 could slip through the net. Time to get the big hammer out again.

[Marc J]

Nooo, not a silly question at all. You'd only need a spare laptop or other small computer to run a server 'stack' (eg Apache, MySQL & PHP) on Windows or Linux.. and you could even set up your own 'ad hoc' wifi network so you wouldn't have to rely on the venue having its own wifi. You could run the web app server in a virtual machine, but I still wouldn't dream of putting it on my DJing machine.

You could even run this on a Raspberry Pi (http://www.raspberrypi.org) :D

I'm running this on a LAMP stacked server (that's Linux, Apache, MySQL & PHP), but you could just as easily run it on a WAMP server (that's Windows, Apache, MySQL & PHP) - or indeed any web server platform so long as it's got MySQL database & PHP5 support. FYI Apache is the name of the web server program, MySQL is the database program & PHP is a programming language.

Surely the problem then would be how people connect? You'd need some way to either get them the IP of the server you're running, or a DynDNS kind of solution...but then that would require a WiFi connection for the lookup...

[Nakatomi]

Surely the problem then would be how people connect? You'd need some way to either get them the IP of the server you're running, or a DynDNS kind of solution...but then that would require a WiFi connection for the lookup...

Okay then.. let's just say it's possible but not really something you'd want to do. Big hassle. Let them eat request slips :) what's the big deal about this needing an internet connection anyway? I've been using it on my own phone over slow wifi and over the air (not even 3G) & it's plenty fast enough. Most of the data is text after all.

I have my own doubts about whether this app is really a 'good thing' or not, but I can see it'd have value before an event to augment a customer consultation.

[funktions]

Okay then.. let's just say it's possible but not really something you'd want to do. Big hassle. Let them eat request slips :) what's the big deal about this needing an internet connection anyway? I've been using it on my own phone over slow wifi and over the air (not even 3G) & it's plenty fast enough. Most of the data is text after all.

I have my own doubts about whether this app is really a 'good thing' or not, but I can see it'd have value before an event to augment a customer consultation.

personally I think its a great thing, I would love to use it. sometimes trying to work out what the spider has tried to scrawl as its legs were being pulled off is just too hard, its great, hence the thought of using it as a local system.
would love to be able to use this properly..

[Nakatomi]

Setting up an open wifi network isn't hard even on windows with free utilities. Install WAMP on a spare laptop, plonk the app on it & off you go.

I could try some things out for that use case & write a howto, but my motivation to do so is low because I don't mind it being reliant on the internet.

You really wouldn't want to run this on a piece of kit you rely on. If your request server gets 'owned' you lose the app. If it was your playout or light controller, yikes

[funktions]

Setting up an open wifi network isn't hard even on windows with free utilities. Install WAMP on a spare laptop, plonk the app on it & off you go.

I could try some things out for that use case & write a howto, but my motivation to do so is low because I don't mind it being reliant on the internet.

You really wouldn't want to run this on a piece of kit you rely on. If your request server gets 'owned' you lose the app. If it was your playout or light controller, yikes

would be a totally separate machine, currently have an i7 920 as play out (slight overkill with 12gb of ram but was in a 19 inch rackmount) dell i7 laptop as lighting controller so another small unit could be easy to fit into the current system. was thinking a nuc mounted to the back of the screen. im sure I can find all the info needed to load everything easily enough. but that's how much I really think you have such a great idea ..

so if "we" all used the system on your server you could harvest some interesting data on track requested, let alone if we actually played them.

[Nakatomi]

would be a totally separate machine, currently have an i7 920 as play out (slight overkill with 12gb of ram but was in a 19 inch rackmount) dell i7 laptop as lighting controller so another small unit could be easy to fit into the current system. was thinking a nuc mounted to the back of the screen. im sure I can find all the info needed to load everything easily enough. but that's how much I really think you have such a great idea ..

so if "we" all used the system on your server you could harvest some interesting data on track requested, let alone if we actually played them.

I can reassure you I have little interest hosting this for other people :)

If you already have web space you likely have the ability to add this app to it, or else your developer does. That's where I'd pitch this thing.

As for the ability to mine requests, I don't even analyse my own. Yet

[Marc J]

If anyone wants to try this out I'll stick a copy / copies up somewhere (I might register a generic domain for it, if I don't have a suitable spare).

Justin - is github syncd with the latest copy?

[Nakatomi]

If anyone wants to try this out I'll stick a copy / copies up somewhere (I might register a generic domain for it, if I don't have a suitable spare).

Justin - is github syncd with the latest copy?

Yeah. I messed up with a code change yesterday, committed it & had to fix that this morning. It should all be in sync.

[Marc J]

I just noticed...it seems host, username, password and db are all hardcoded in conn.inc.php, yet they are defined in configuration.php.

As this is probably one of the few things that'll change between installations, shouldn't conn.inc.php pull these from the configuration.php file, so that it's a one-place-only change?

[Nakatomi]

I just noticed...it seems host, username, password and db are all hardcoded in conn.inc.php, yet they are defined in configuration.php.

As this is probably one of the few things that'll change between installations, shouldn't conn.inc.php pull these from the configuration.php file, so that it's a one-place-only change?

conn.inc.php needs to be cleaned out. Not used. Includes could do with a tidy up too - this is my first 'standalone' code mangling project remember

[Marc J]

conn.inc.php needs to be cleaned out. Not used. Includes could do with a tidy up too - this is my first 'standalone' code mangling project remember

Ah...that explains it then! I should have looked deeper....;)

[Marc J]

I've just added a few issues on GitHub (I use a different name there ;)).

Also....you'll probably shout at me but my dev server (a QNAP in my cupboard) PHP doesn't support mysqli, only mysql. Any chance this can be a configurable option? (I just checked.....there are 231 times this is used) :p

[Marc J]

Admin username and password are plaint text in the database...shouldn't these be salted and / or md5 hashed?

The readme says there's no need to add http:// to the base URL....what happens if you want to use HTTPS? I'd recommend changing this so the whole URL (including http or https) has to be entered...

[Nakatomi]

Admin username and password are plaint text in the database...shouldn't these be salted and / or md5 hashed?

The readme says there's no need to add http:// to the base URL....what happens if you want to use HTTPS? I'd recommend changing this so the whole URL (including http or https) has to be entered...

I thought about salting the passwords but is it really necessary? Maybe, and not much work to fix.

As for mysqli, I ain't budging on that. MySQL is deprecated & its use is actively discouraged. I started out using mysql as you'll see in the commit logs (maybe).

The rest of the issues you've flagged, I'll get onto soon.

By the way, thanks for your help so far :beer:

[Marc J]

As for mysqli, I ain't budging on that. MySQL is deprecated & its use is actively discouraged. I started out using mysql as you'll see in the commit logs (maybe).

Haha, that's the answer I was expecting! I think a firmware update might give me mysqli on the QNAP....will have a look.

[Nakatomi]

Haha, that's the answer I was expecting! I think a firmware update might give me mysqli on the QNAP....will have a look.

If the older method wasn't so actively discouraged & you were willing to lend a hand in abstracting the db code out to functions I'd definitely work with you on making it either/or - make no mistake on that score. I'm starting to think that abstraction is going to be a good idea anyway.

Oh, and anybody worried about anybody aggregating your requests data.. the app can't do that. When you delete an event, the requests go byebyes too. At least they should.. maybe I've forgotten to put that line in :lol: It would definitely be interesting to be able to collect request data for our own uses, and indeed for multi-op bosses to check up on their minions (insert evil laugh emoticon here). That would be a piece of cake to do.. rather than simply deleting requests associated with an event, copy those request table entries into a 'master request history' table.

Please feel free to help me out & hammer the living daylights out of the test account. It seems to do what it's supposed to do in a roundabout way, but as any fule know there are always what devs call 'corner cases' lurking so the more live testing this gets the better.

Anyone else lurking with any PHP coding chops, help yourself to studying the code & making suggestions to improve it - be critical if you like so long as it's constructive (i.e. don't just say it's crap. Say "that's crap, but if you did this...").

[Marc J]

If the older method wasn't so actively discouraged & you were willing to lend a hand in abstracting the db code out to functions I'd definitely work with you on making it either/or - make no mistake on that score. I'm starting to think that abstraction is going to be a good idea anyway.

Looking at some software I've got that gives the option between MySQL and mysqli, they do it by changing the included file, e.g.: -

include("./functions/dbAccess_".$databaseType.".php");

with 2 files - dbAccess_mysql.php & dbAccess_mysqli.php...both with all the functions required for each method.

To do the same would be a lot of work, especially considering you've done the exact opposite already to remove mysql! I don't mind lending a hand (time permitting) but as you say, mysql is deprecated and so we should really be moving away from it...

[Nakatomi]

Looking at some software I've got that gives the option between MySQL and mysqli, they do it by changing the included file, e.g.: -

include("./functions/dbAccess_".$databaseType.".php");

with 2 files - dbAccess_mysql.php & dbAccess_mysqli.php...both with all the functions required for each method.

To do the same would be a lot of work, especially considering you've done the exact opposite already to remove mysql! I don't mind lending a hand (time permitting) but as you say, mysql is deprecated and so we should really be moving away from it...

Marc, I'm looking to start abstracting out the database stuff before I go putting any more db code in there. Do you have any ideas where I should look for a ready made class or other DB wrapper? PDO seems like a good idea, but I'm just wondering about your thoughts on this. I'm going to take a look at Prestashop (the other thing I look after) & see what they use. If it's simples enough I'll 'borrow' it

[Shaun]

Looking at some software I've got that gives the option between MySQL and mysqli, they do it by changing the included file, e.g.: -

include("./functions/dbAccess_".$databaseType.".php");

with 2 files - dbAccess_mysql.php & dbAccess_mysqli.php...both with all the functions required for each method.


Swahili....people talking Swahili everywhere I look. :d

[Marc J]

Marc, I'm looking to start abstracting out the database stuff before I go putting any more db code in there. Do you have any ideas where I should look for a ready made class or other DB wrapper? PDO seems like a good idea, but I'm just wondering about your thoughts on this. I'm going to take a look at Prestashop (the other thing I look after) & see what they use. If it's simples enough I'll 'borrow' it

The example I've got is from the ecommerce package I use. It creates a dbAccess class which has all the functions needed...the only difference between the two files are the mysql and mysqli differences.

It's probably a bit late in the day to be changing stuff on this app? Unless you're planning to add more to it, I'd say it's probably not worth it if it works as it is. BTW a firmware update will give me mysqli on my QNAP (dev server), and I doubt there are any live servers running less than PHP 5.2.9 - so doing any extra work just to support mysql is probably a waste of time (IMHO).

By all means PM me if you want to take a look at what I've got, I can email it over to you...

[Nakatomi]

I'm looking at this from the angle of maintainability. A couple of DB functions will be easier to maintain. It should be fairly easy to port the code to using a DB class once I've cracked it.

[Marc J]

OK, well as I said just PM me if you want a look at the stuff I have...although it's probably a bit OTT!

I've added to an issue on GitHub...just tell me to STFU any time if you like :D ;)

[Nakatomi]

OK, well as I said just PM me if you want a look at the stuff I have...although it's probably a bit OTT!

I've added to an issue on GitHub...just tell me to STFU any time if you like :D ;)

Ok, STFU!
Nah, these sort of things are important to squish, so keep em coming :)

I messed about earlier and got some DB functions working outside the scripts creating pages. This should make error trapping easier among all the other possible benefits.

Good suggestions in the issues btw, I'll get onto those soon.

Next up, password salting and lost password recovery.

[Nakatomi]

Update: With things being a bit more than uncertain on the day job front for the last couple of weeks I've not felt able to continue coding this - but since an offer was made to me yesterday I'm back on the wagon.

I've started fleshing out code for salted passwords for system users.

[Marc J]

Update: With things being a bit more than uncertain on the day job front for the last couple of weeks I've not felt able to continue coding this - but since an offer was made to me yesterday I'm back on the wagon.

I've started fleshing out code for salted passwords for system users.

Good news all round :beer1:

[Nakatomi]

Update: I've chipped away at some code recently so I've not completely stalled on this.. I still need to do some work on the forgotten password stuff. No point it being password protected if you forget your own password innit

[Excalibur]

Swahili....people talking Swahili everywhere I look. :d

I'm so glad you said that, Shaun. So we can delete the whole thread as a breach of my beloved Rule 23 then? :whistle:


Only kidding lads, even though I don't understand a word of it, I think it's a fantastic idea. More power to your voodoo. :D:D

[funktions]

I have always said this is an awesome idea and think it has some great ideas. top marks to you sir for all your hard work.. my dj partner/web man has been impressed on how easy it was to get running, he was a little worried it would be a pain to install and tweak but was very surprised on how neat it was.

[Nakatomi]

I have always said this is an awesome idea and think it has some great ideas. top marks to you sir for all your hard work.. my dj partner/web man has been impressed on how easy it was to get running, he was a little worried it would be a pain to install and tweak but was very surprised on how neat it was.

It's only going to get easier too. I learned how not to make a web app from my last day job but one. It was a hellishly difficult thing to install, which led to me fixing that & ultimately making scripts to package it so any old luser could install it. Mind, I doubt many apps start their life being bloated & pigs to install ;)

Thanks for the feedback :)

[Nakatomi]

Right then.

I still haven't forgotten about this thing - I've just been eyeball deep in other things. I'm planning to resume work on this soon I promise. I'm gonna need it for my own site :)

[Marc J]

OMG! I finally got around to "bootstrapping" the front-end of this. See http://ask.elitedj.co.uk and use event key mdddemo

I haven't touched the back-end so see Justin's posts from around #70 (http://www.forum.mobilediscodirectory.co.uk/showthread.php?42433-A-request-web-app/page7) for a link to the demo of that.

I started with the copy I had from Github months ago, but from the look of it it's the most current (at least from what's there now).

Thanks for all your hard work Justin! I'm not sure if the back-end needs a makeover, as the most important part is the public facing side of it. I've got to tidy it up a little and there are a few issues, but I'll get a copy of it to you (PM me your email address).

Also, let me know if you've made any changes or corrections to the code (not on Github). It may be hard to merge them in to what I have, but not impossible...

:beer1::beer1::beer1::)

[Nakatomi]

Wahaha talk about Kismet!

I just started dabbling about with it again yesterday. I remember getting some of encrypted password storage working but then I couldn't remember any of the login details - and they're now encrypted in the database :lol:

I'll give the bootstrapped version a peek Marc cheers.

[Shaun]

OMG! I finally got around to "bootstrapping" the front-end of this. See http://ask.elitedj.co.uk and use event key mdddemo

I haven't touched the back-end so see Justin's posts from around #70 (http://www.forum.mobilediscodirectory.co.uk/showthread.php?42433-A-request-web-app/page7) for a link to the demo of that.

I started with the copy I had from Github months ago, but from the look of it it's the most current (at least from what's there now).

Thanks for all your hard work Justin! I'm not sure if the back-end needs a makeover, as the most important part is the public facing side of it. I've got to tidy it up a little and there are a few issues, but I'll get a copy of it to you (PM me your email address).

Also, let me know if you've made any changes or corrections to the code (not on Github). It may be hard to merge them in to what I have, but not impossible...

:beer1::beer1::beer1::)


Ooooh, a shiny new toy! ;)

Cheers Marc...and Juski. :beer1:

[Excalibur]

OMG! I finally got around to "bootstrapping" the front-end of this. See http://ask.elitedj.co.uk and use event key mdddemo



Am I correct in assuming that Shaun is likely to soon be flooded with daft requests from us lot?


Whoopee. :D

[Nakatomi]

Right then.

I've squished a bug or two & I think encrypted password storage (and updating) is now working properly. Time for me to be a git committer again. You know what, this is the first thing I've ever written I think where I've gone back after months of not doing anything & I know what it's doing! :O

Next thing to do will be to make forgotten password retrieval work.

[Nakatomi]

Loads of changes checked in. The front end is now all bootstrapped thanks to Marc's stirling efforts & he's come up with a few fixes for security I hadn't thought necessary.

Multiple events should now be handled better & forgotten admin user passwords can now be reset.

I've started carrying Marc's front end changes into the back end too.

Fyi anybody using old versions of this might want to update your code so that strings obtained from site cookies are escaped to prevent SQL injection attacks. The risk is pretty low but you know.... Best practice & all that stuff.

Still to be done is an installer page to initialise the database. Among other feature improvements.

[Nakatomi]

17777

I've now got loads done.. and have begun the joyous task of converting the backend to bootstrap too.

[Nakatomi]

Almost all the backend stuff is properly converted to bootstrap now (which for most of you means not very much except muggins has been working on a lot of stuff).. and improvements are afoot.

I was looking at the custom text stuff tonight.. and wondering why the heck there's a user ID field in the custom text database table... OH YEAH.. it's so individual system users can have their own custom texts. Well you know what? I'm sacking that feature unless somebody can give me a good reason not to. I'm not sure I ever implemented it properly anyway. Infact I've even wondered why it wasn't just put in a config file instead. It's not like it's something that's going to need changing very often is it?

[Marc J]

...it's so individual system users can have their own custom texts. Well you know what? I'm sacking that feature unless somebody can give me a good reason not to. I'm not sure I ever implemented it properly anyway. Infact I've even wondered why it wasn't just put in a config file instead. It's not like it's something that's going to need changing very often is it?

I have to agree, the whole text definitions (not just per user) is something I would have put in a config file from the start. Once set they'll rarely change, IMHO.

One thing I noticed...when in admin if something's blank (e.g. a request message) you can't seem to be able to click on it. I think you'll need to style the td.message .grid_content .editable span as clickable in these cases?

Bootstrap has its own show / hide mechanism which you may be able to use to simplify things or make it easier in these admin tables - see the 2nd (currently 98 votes) answer at http://stackoverflow.com/questions/23873005/hide-div-by-default-and-show-it-on-click-with-bootstrap - basically give initially hidden things a "collapse" class and do it all with unique IDs and data-toggle / data-target...

[Nakatomi]

I have to agree, the whole text definitions (not just per user) is something I would have put in a config file from the start. Once set they'll rarely change, IMHO.

One thing I noticed...when in admin if something's blank (e.g. a request message) you can't seem to be able to click on it. I think you'll need to style the td.message .grid_content .editable span as clickable in these cases?

Bootstrap has its own show / hide mechanism which you may be able to use to simplify things or make it easier in these admin tables - see the 2nd (currently 98 votes) answer at http://stackoverflow.com/questions/23873005/hide-div-by-default-and-show-it-on-click-with-bootstrap - basically give initially hidden things a "collapse" class and do it all with unique IDs and data-toggle / data-target...

The editing code needs javascript (spit.. pting!) to be able to update the fields anyway, so I don't think it's much of a simplification. I'll look at giving table fields a minimum width - that might give a clickable target at least.

I've started work on ripping out all my hard work on customtext code & putting text customisation into a file instead. Heh. Hard work. Nah. Busy work more like.

[funktions]

necro i know...

what ever happened to this ??

[Marc J]

necro i know...

what ever happened to this ??

Almost got there....if I recall correctly it's almost usable (in fact I think some do use it) but the version myself and Justin were working on required some final tweaking (I think myself doing the forgot password page) but it's a while ago and other things took priority. If Justin wants to resurrect it and we could work on finishing it, I'd be up for that...I just can't quite remember where we were!

[Nakatomi]

necro i know...

what ever happened to this ??

I stopped doing walkin gigs at the venue that necessitated remore request giving & besides I think asking in person is by far the method I prefer customers & gursts to use.

[Nakatomi]

Or what I should have said was


I stopped doing walkin gigs at the venue that necessitated remote request giving & besides I think asking in person is by far the method I prefer customers & guests to use.


In short, it didn't get any further. And now I just use MDJM (https://mdjm.co.uk/)

[Marc J]

Given social distancing rules...maybe time for a bump?

This is still where it was left over 4 years ago, but if there's interest then I might go back and take a look at finishing it... in collaboration with Justin if he's willing!

Quick link to the live demo: https://ask.elitedj.co.uk (use code mdddemo)

[Nakatomi]

Given social distancing rules...maybe time for a bump?

This is still where it was left over 4 years ago, but if there's interest then I might go back and take a look at finishing it... in collaboration with Justin if he's willing!

Quick link to the live demo: https://ask.elitedj.co.uk (use code mdddemo)


Maybe Marc, maybe.. but I'm a bit busy at the mo getting on with a new light fixture I'm designing.

[Nakatomi]

Maybe Marc, maybe.. but I'm a bit busy at the mo getting on with a new light fixture I'm designing.

I kind of rekindled my interest in taking requests electronically a while back, partly spurred on to minimise the amount of admin pre-event requests can cause (mostly in transcribing the blessed lists). I figured out how to import a VDJ database, make a list of requests that the app can spit out a .M3U file of I can just drag & drop into VDJ. Thing is, I've no idea where I put the code :cry:

EDIT: I found the code! I'll waz it up on my github somewhere ASAP..

EDIT: And HERE (https://github.com/jhornsby/DJRequestWithAjax) it is :) No, don't ask me what any particular PHP function does - all I can remember is it's /client for the customer side, /guest for guests & /admin for admins.