DF Guild Application w/ Recruitment Block

by **Razac** » Fri May 11, 2007 8:27 pm

Additional Note..

I am looking into perhaps a javascript function that will check the Class selected and add additonal questions based on class.

As my guild seems to think there should be class specific questions.

by **Razac** » Sat May 12, 2007 3:04 am

Strike that last comment...

I had talked to the RL and told him it would be a lot of work to add an Unknown amount of fields to the application per class.

Instead I will be adding a section to the admin page that will allow admins to list pre-requisites for each class

ie mage must have 1000 Minimum to damage etc...

this will then display when the user selects the class

by **robojerk** » Tue May 15, 2007 5:49 am

I know this is kind of a double post (see adding video to bbcode) but it belongs here as well.

ForumsPro 2.0.1.0 is going to be released soon..

http://www.myndworx.com/index.php?name= ... cle&sid=33

change log wrote:We've just installed the 2.0.1.0 release candidate here at MwA and it's up and running on the Forums here.

Currently, here's whats coming up in the next release.........

05/09/2007 - v2.0.1.0
---------------------
+ Upudated version to 2.0.1.0 since this is a semi-major release due to removal of nbbcode dependancy.
! Fixed missing forumspro_ in get_code_lang call inside smilies routine
! Fixed email notification links bug. http://myndworx.com/ForumsPro/viewtopic/t=1222.html
+ Admin panel controls added for four new features. (Display custom fields in viewtopic, limit signatures to certain groups, require guests to verify the security image when posting, display users online today.) Please note that the user side of these features is incomplete.
+ Collapsible categories
! Fixed RSS for XML validity when LEO is off. Added guid and cleaned up misc quoting.
! Fixed bug 148, allowed attachment extensions and sizes link
- nbbcode.php is no longer used, fpbbcode.php is now used. Renamed functions and classes to avoide conflicts with nbbcode.php
- Added buttons for spoiler tags and strike tags, please note these features are not complete yet.
+ Spoiler and strike tags now added. Thanks Brennor with changes to your original spoiler tags
- bbcode.js is no longer used either, now fpbbcode.js is used. language/english/bbcode.php no longer used, fpbbcode.php now used.
! Fixed helptext in spoiler tag
! Fixed this bug: http://myndworx.com/index.php?name=Foru ... pic&t=1202 permissions errors. Thanks Alberon.
! Fixed feature request 137 (which I believe is really a bug). Ignored users now stay ignored until unignored.
+ Renamed center blocks to a) be more descriptive and b) not overwrite old blocks if not desired. Blocks enhanced to add forum name, see feature request 135.
! Small XHTML fix
+ Added forum name to Your_Account blocks
- Gave Your_Account blocks and center blocks their own template so that they can now be edited without also changing the topics_list template
+ Feature request 124, added find all posts by this user link to Your_Account block
! Small bug with theme selection in collapsing categories

This may have some serious issues with the application module. Someone will need to investigate this.

by **Razac** » Tue May 15, 2007 10:33 am

when it gets released I will install it and see what breaks..

by **robojerk** » Tue May 15, 2007 10:42 am

Razac wrote:when it gets released I will install it and see what breaks..

Myndworx is using a release canidate, I sent you the SVN addreess if you wanted to look at it

by **Deeo** » Tue May 15, 2007 4:39 pm

Razac wrote:Strike that last comment...

I had talked to the RL and told him it would be a lot of work to add an Unknown amount of fields to the application per class.

Instead I will be adding a section to the admin page that will allow admins to list pre-requisites for each class

ie mage must have 1000 Minimum to damage etc...

this will then display when the user selects the class

sounds quite nice. and i am glad to hear, that you are okay.

what about german translation?

i would translate the actual version, but if there is a new one. All the work would be gone.
Or could i increment the changes directly? If yes, i will translate it nearly. if not, i will wait until a full version.

--> using language files would be also an idea! Dragonfly is supporting this.

by **Razac** » Tue May 15, 2007 8:06 pm

Hmm Sorry English being my main language which im bad at anyways LOL I didnt consider others.

perhaps when I finish this new portion of the application I will create a language file.

I am almost done this part anyways..

TY. FYI when ya go agaisnt a transport truck you tend to lose .

Write that down.

Robo I will take a look at it TY

by **Deeo** » Tue May 15, 2007 10:08 pm

ive no problem with that

just thought that a language file would be easier to translate and esier to use with DF.

by **Razac** » Wed May 16, 2007 3:34 am

Okie then.

here is v2.1 with the added changes mentioned above.

Please test this for me. everything seems to be working fine for me.

If you already have this installed I created a small update.php file that you can run to alter your existing tables.

Download Application module v 2.1

by **Anaxent** » Wed May 16, 2007 5:36 am

The update querys should be added to the cpg_inst.php in the update section and to the main install section for new installs.

edit: I just built the new cpg_inst.php and am about to test it right now

by **Razac** » Wed May 16, 2007 6:59 am

LOL oh yeah.. Duh...

let me know how that goes.. then post it and I will add it into the zip..

by **Anaxent** » Wed May 16, 2007 7:06 am

So I have the updater working good now and have went through some of the files and found module.php being sued so i added the getlink() function let me know if there is anything else.

by **Anaxent** » Wed May 16, 2007 8:26 am

Im thinking we should also define wowrosterdf install name for appconfig.php and rewrite the installer to use
$this->prefix = strtolower(basename(dirname(__FILE__)));

example

Code: Select all: class Application { var $radmin; var $version; var $modname; var $description; var $author; var $website; var $dbtables; function Application() { $this->radmin = true; $this->version = '2.1'; $this->modname = 'Recruitment_Settings'; $this->description = 'Recruitment mod'; $this->author = 'Ymryl who created this for the PHPNuke users and to Anexant, Robojerk and Rasac for Dragonflycms'; $this->website = 'www.wow-deception.com'; $this->prefix = strtolower(basename(dirname(__FILE__))); $this->dbtables = array($this->prefix.'_recruitment', $this->prefix.'_recruit_data'); } function install() { global $installer; $installer->add_query('CREATE', $this->prefix.'_recruitment', "

Making the installer this way will allow the folder name to be diffrent which in theory would allow multi installs of the app for diffrent guilds..
Or I should look at rebuilding this for roster 1.8 as an addon so it could be used by every guild out there and maybe have switches for forum posting per forum type... huh ideas so many ideas

by **Razac** » Wed May 16, 2007 8:34 pm

I think we are taking a module and trying to push the envelope.

I think leaving it as a stand alone DF Module will be fine. It can still be used by every guild, It just doesnt require Roster. Or are you refering to breaking it out of a DF module and make it work on any Roster install?

perhaps making a swtich between Forums and ForumsPro would be good.
nothing worse when ya want to use something and then find out the requirements to use it. currently this requires Forums Pro 2.0+ to use the forum posting feature.

by **Razac** » Wed May 16, 2007 11:30 pm

Here is an updated version that fixes a CSS issue with displaying Class pre-requisites...

recruitment_module_v2.1[2].zip