Note, you can find all of the past release notes, installation instructions and README information for WRM at: * http://www.wowraidmanager.net/wiki/index.php?title=Installation **************************************************** **************************************************** **** 4.0.4 Release Notes *** **************************************************** **************************************************** So it's been a while and I thought I'd go ahead and release a new version. This is mostly just a maintenance release for the known bugs and additional instances to make it "easier" to install without having to go through all the patching. There are one or two small fixes to this code that were not included in the patch thread, so it's probably worth uploading anyway. * Patch fixing role limits not being honored when drafting to a raid have been fixed. When drafting queued people to raid, the role limits set for a given raid were not being honored due to a bad check. * Patch fixing image locations on Bliz Armory Website and fixing character portraits for characters above level 70. * Two issues with the "roster" page have been discovered. First, the "role" field is blank. This is due to a misconfiguration in the database that should be showing "primary spec" and "secondary spec" in this slot instead of "role". Secondly, the "Profile" link is shown to all users instead of only those with "users" priviledge, this causes hacking attempts when users of the software click the profile link and do not have the "users" privliedge. * An issue with the Armory code causes international users (European mostly) to be forced to lookup guild and charcter information on the regular wowarmory US website, causing nothing to work. The update file in this thread will patch the phpArmory.class.php file in the phparmory042 installation and make it work correctly. * An issue with sorting in all data tables in all foreign languages (languages other than English) has been discovered. Users using a language other than english will find that clicking a column header in any data table to sort that header (where the header text is different from the english language text) will incorrectly sort the table. * An issue with users being unable to create characters in the profile page. The dropdown for "race" is not filling in which stops all of the rest of the form from being accessable. The issue is that the config option for your faction (alliance/horde) is in lower case but in the Race table (where the factions are allocated) are in upper case (alliance vs Alliance). In MOST cases, MySQL is case independent in this situation and selecting from the race table by the lower case faction name does in fact pull back races with an uppercase faction name, in some installations, however, this is NOT the case. * Patch for adding icons/raids for Trial of the Crusader * Patch for adding icons/raids for Icecrown Citadel * Bugfix: code doesn't use max number of RSS feeds to display. Missed the incriment of the $i variable. * Fix for windows includes. There are problems with relative pathing in a windows installation that are corrected by this update. This should, hopefully, make WRM run smoother in a windows environment. **************************************************** **************************************************** **** 4.0.3 Release Notes *** **************************************************** **************************************************** LOTS of little things fixed in this release, this is a general bugfix release over 4.0.2 and HOPEFULLY will be the last 4.0 release I produce, 4.1 will be next with several new features. As always report any issues you see with the 4.0.3 product and I'll patch it. * Minor installation fixes including a wrong name in a table drop, wrong version display in the installation header (read 3.x.x instead of 4.x.x), and a generic fix to all bridge files to update the default location to look for the CMS/BB configuration file at ../../ instead of the useless ../< blah > that was in there right now. I suspect that this change will fix several "I can't find my config file" problems right off the bat. :) * SMF Authentication fix: SMF Subgroups are now supported. A bug causing players in a sub group of SMF to not be able to authenticate has been fixed. * Fixed minor bug with buttons on the guild list (edit/delete) not showing up. * Several issues to the armory look up code have been fixed including: * URL Encode Failed: issue with replacing " " with "+" in functions.php caused URL encode issues at the lookup point. Both functions.php and the lookup were doing an encode on the URL and thus the " " got encoded twice and failed. * Talent Spec Lookup Bug: Bliz changed the armory output to include a "talentSpecs" node between the class node and the previous "talentSpec" node that caused talent spec calculation lookups to fail. * Support for Multiple Talent Specs: Support for dual talent specs added by looking up both specs and processing all nodes under the new "talentSpecs" node. Single talent and dual talent specs are now supported. * Added Debugging: Additional debugging has been added. The output from the curl call and the output of the generated PHP character array has been created on disk for debugging purposes. Additionally for 042, each connection (patch notes, talents, character sheet, pvp data, etc.) will generate their own data and stderr files on disk. * Changed armory 020 Method of Encoding URL. The 020 version of the armory code was encoding the URL entities (realm, character) manually. Changed this to use "urlencode" which should do all the right stuff. * Changed the default and wowhead templates to now display both primary and secondary talent specs. * Fix added to the web based "Do I have the most recent version" lookup where a hard coded "3" for the major version was causing problems. Also made the code a little cleaner and easier to read. * Fixed an issue where a red X appeared in the locations page in place of the raid image in certain conditions on Internet Explorer (Real browsers, like Firefox, were unaffected *grin*). * Joomla Authentication fix for using the alternate authentication group (subgroup). Had a typo that was causing this group not to work. * WRM LUA Output problems: When using the LUA output in 4.0.x with a language other than "english" selected as your default language for WRM, a problem occured with class lookups: the code expected to see the localized names of the classes upon lookup but was getting only english class names and thus failing. See the "i18n/l10n Fixes" header for more information on LUA changes. * General Bridge Update: All bridges have been updated to PROPERLY accept and handle multi-byte characters both as part of the username and as part of the password. Users should no longer get "locked out" of WRM because their usernames don't match due to a multi-byte character in them. This should be fixed across the board, but for SMF/SMF2 especially this was a headache (username is part of the hashed password). * Minor fix to the case where WRM displays an error message so that the page doesn't actually load when an error displays. This is the behavior as it has been in WRM up to 4.0, this is just a return to that behavior. * Fixed a "permissions" issue that was reported by a user where their permissions IDs were not being properly allocated to the respective permissions groups. Permission ID "1" is identified by the system as "superadmin" in all cases, if for some reason the permission ID of the "superadmin" group is not 1, the system no longer thinks it's GOT a superadmin. This is actually a very POOR implementation of permission IDs and will be fixed in a future version when I do a full permissions system re-write. * Updated the "class" table in WRM to now carry the offical class index number (blizzard identified) for use by both the armory code as well as within WRM. This should allow WRM to better interface with properly written external applications that support the blizzard class index numbers. These "blizzard" numbers are now used across the system instead of the arbitrary numbering scheme of previous releases. * Fixed a bug in table pagination in the "missing signups" link from the "raid view" area. If the missing signups decided it needed to paginate, it would not do so properly. * Fixed a bug in several areas (Profile, Roster, Teams) where the player class was always displaying in "english" regardless of the foreign language selected. This update should properly display the character classes in the localized format. * Thanks to user reports, I have fixed a bug in the Users.php file that caused the primary and secondary spec NOT to display in the drill down (user details) view. (Thanks Vollheilig) * Added 8 new CSS classes for Theme developers, including 3 that get rid of the need to modify the functions.php file. See "CSS Updates" Section below. i18n/l10n Fixes ------------------- I swore I was going to do it at some point and I have. The largest and most prominent update in 4.0.3 is one you won't see on the screens anywhere. As far as I can tell ALL internationalization (i18n) and localization (l10n) problems within WRM have been SQUASHED. I now have a proper UTF-8 connection from the code to the database and back so all data being sent and received is now in correctly translated UTF-8 Code. I have also updated all of the string code in the system to use the multi-byte aware versions of the string codes (replacing things like strtolower() with mb_strtolower() to ensure proper UTF-8 Handling). What this means for all of you out there is we should STOP seeing these annoying login issues where users with funky names are not recognized correctly and thus not authenticated with the system. WE should now even see all of the text on the screens with properly displayed accented characters instead of the junk you used to see. HOWEVER, there is a catch. Any information with multi-byte characters that has already been entered into the system MAY fail to behave properly at this point, even information that has worked in the past. The "FIX" for this is to re-create the data. So for instance if you have a guild name with a multi-byte character in it, and it's not showing up correctly for you or causing you problems, delete it and re-type it in and re-store it to the DB, from there out, it shouldn't cause you any more problems. Same with character names or accounts. While this might be some work for you and may cause you some failures in the near term, in the long run you will no longer be seeing any multi-byte issues in the system (I HOPE). Please, before reporting a multi-byte issue or an issue with a multi-byte character as part of the input, please see if you can "remove" any existing information associated with the problem and re-create it on your system to see if the problem goes away BEFORE reporting the issue. If the data is simply too much to re-input, you CAN go in to the tables directly and edit the information directly. If you are stumped as to where to find a particular value, please don't hesitate to ask me. A second note: Regarding the Output LUA file. If you notice that the output LUA file is no longer being translated into a foreign language (particularly class names) for 4.0 that is because it's not. This is not a bug. It is easier for the communication protocol between WRM and RIM to be 100% english text and to allow the respective systems (WRM and RIM) to do the translations into the foreign languages we support at display time. What this means is that where you USED to see "todestrider" before (in german) you will now see "deathknight". You should see these properly displayed to you localized in the respective applications however. CSS Updates ----------------- Thanks to a set of conversations I had with donflamenco, there have been 8 additional minor CSS elements added to the templates/default/style/stylesheet.css file. The elements are identified as follows: * badcolor, goodcolor, evencolor: These three elements are used in the includes/functions.php file in the "get_color()" function. Used to be that the theme developers had to modify this file if they wanted to change the "green, red, black" colors on the data tables when certain conditions apply (for instance when the raid leader doesn't have enough of a class to meet a set raid limitation, the number showed up as "red"). Instead of the "font" code imbeded within the function, this has been changed to a span with a class that is now controlled through these three CSS elements. "badcolor" is the element used when a condition is out of bounds (either over or under depending upon condition), "goodcolor" is the element used when a condition is "good" (under limit with spaces available, at or above the minimum of a given class, etc.). "evencolor" is used when a condition matches a stated value (i.e. 10 of 10 DPS have signed up to the raid...it's not over and it's not under). Three more elements have been added to affect the Calendar: * priorDay, currentDay and postDay: Affect the font, color and size of the NUMBER displayed in each calendar box. Note ONLY the number and not the box itself is affected by these three elements. Template developers can feel free to set different colors for the different day types (before Today, Today, and After Today) based upon the theme they've selected. Note that the "key" below the calendar is tied to the same class as the calendar numbers are, so changing the color of the number through the CSS value will also update the "key" to allow users to make sense of your colors. And finally two elements have been added to affect the signed up mark and the queued / cancelled mark on the calendar: * draftedmark - Affects the "*" mark next to the raids on the calendar which identifies when a user is signed up and drafted (selected to come) to the raid. * qcanmark - Affects the "#" mark next to raids on the calendar which identifies when a user is signed up to the raid but has not YET been drafted (queued) or the user has signed up as "cancelled" to the raid. Both of these elements affect the size and color of the * or # used to identify one condition or the other. Again, the Key uses the same class as the text itself so that an update to the color or size will affect both the mark on the calendar, as well as the key below the calendar in the same way. Each of these elements is documented, at least minorly, in the CSS file. Theme developers, please update your themes and EXCLUDE/REMOVE the functions.php files from your theme (there is no need to update that file anymore, all design elements in it are controlled through the new CSS elements) and update your themes to make use of the new calendar and condition colors. **************************************************** **************************************************** **** 4.0.2 Release Notes *** **************************************************** **************************************************** * Fixed bug with drafting. Only half the number of users were allowed to be drafted. This was caused by the code counting class and role counts together for total raiders instead of counting EITHER the class signups OR the role signups. * Addition (Re-Addition) of "Role" column for Queued and Canceled members allowing sorting by role on the queued and canceled sections of the raid view. Sorting by role is done automatically on the drafted views. * Modified the Cache and compile directories for the smarty template engine to point to ./XXXX/ instead of just XXXX/ which was causing problems for MS Windows/IIS hosts. INSTALLATION ---------------- Follow the standard installation instructions included in docs/INSTALL UPGRADE ---------------- As with other 4.0 releases, please DO NOT use the upgrade utility / installer. Instead look in the install/database_schema/upgrade directory. In it you will see 3 files: 3.6.1_4.0.0.sql = This file will take you from 3.6.1 to 4.0.2. If you are currently on 3.6.1 this is the file you want. FOLLOW THE INSTRUCTIONS IN THE INSTALL DOCUMENT AND ON THE WEBSITE beta1_4.0.sql = This file will take you from WRM beta 1 (3.9.9.1.2) to 4.0.2. Again, follow the install instructions carefully (upgrade section). 4.0.1_4.0.2.sql = This is a small SQL file that will take you from 4.0.1 to 4.0.2. Make sure to change the table prefix on the tables in this file BEFORE executing the code (change wrm_ to your table prefix). **************************************************** **************************************************** **** 4.0.1 Release Notes *** **************************************************** **************************************************** Quick Release Notes for WRM v4.0.1 ------------------------------------ This release is a consolidated patch release for 4.0 fixing all known bugs with the WRM system. Bug fixes include: * Class/Role Counts Problem: The class/role counts on most pages (raids, index, locations, raid view, etc.) were incorrect due to several problems with the count methodology. This is now fixed. * Installation Failures: Fixed Installation SQL which had several failures with duplicate column/table name and other SQL issues. * Raid View by Class Error: Viewing raids by class (as opposed to by role) was throwing an error due to a bad "{section}" in the HTML code. * Several Sorting/Pagination Problems Fixed. Several sorting and pagination problems have been fixed resulting from lack of default sorting and improper parameter checking during page switches in data tables. * Teams View: Delete from Team buttons not showing up. A fix has been included for the teams view (adding/removing users from raid teams) where users once added to a team had no ability to be removed from that team (the delete button wasn't there). * Teams View: Fix for "Hacking Attempt" when adding users to a "null" team. When users were being added to a "blank" team (i.e. no team defined and users selected for addition) a "hacking attempt" was being generated by the system. It has now been changed to be a "Form Error" identifying that no team was selected for the user to be added to. INSTALLATION: --------------- All users upgrading must run the following SQL into their database: INSERT INTO `wrm_version` VALUES ('4.0.1','Version 4.0.1 of WoW Raid Manager'); Where "wrm_" should be changed to the table prefix for your installation. **************************************************** **************************************************** **** 4.0 Release Notes *** **************************************************** **************************************************** Release of 4.0.0 Final of WoW Raid Manager ----------------------------------- -- 4.0 Final Release Changes. * NOTE: Many items do not have configuration options. As this version of WRM was NOT expected to be released for several months, keep in mind that it is somewhat "rough" around the edges when it comes to support for new features. For instance, the system supports column visibility modifications (being able to hide/show columns on the fly for any given data table) yet does not have an interface to be able to do this. Users will have to modify the database records directly to be able to modify the hide/show on each column in a data table. There are several places where new features may not have an interface, advanced users may feel free to make modifications. Normal users will need to work "as is" with the system till I can get another version out that supports these changes. * Database Reorganization/Restructuring/Normalization. The major change with this release is a full database reorganization and normalization and the addition of multiple new tables. With this release WRM has almost doubled the total number of tables and more importantly has gotten to a point where hard coded wow specific data has mostly been removed from the system if not completely. With the release of WRM 4.0 it should be SIGNIFICANTLY easier to use this system for games OTHER than World of Warcraft, though the development will still remain WoW Focused. For those looking to migrate this application for use in other games please see the races, classes, roles, gender, and the various cross ref tables (class_race, class_role, etc.) * General Code Cleanup. There has been a general code clean up of many of the major sections of WRM. Confusing code (like raids.php that intermixed various bits of code based upon whether or not certain conditions were set) have been expanded to make flow more followable, while large sections of code like view.php have been condensed and normalized, cutting out several hundred to a couple thousand lines all together. In general, the code should be much more easy to read and follow than it was before. * Easier addition of WOW Data, along with the changes to normalize the database we have gained the abililty to add new data to WRM without the need to rev the code/release a new release. Additions of classes, races, roles, etc. are all now accomplished by adding rows to a data table instead of hard coding them into the WRM code itself. * Role Support beyond "6". Not that there's been a request for this, but we are no longer limited to 6 "pre-defined" roles in WRM. There is now the ability to add an unlimited number of roles to the system and have the system recognize and display those roles. Please note, however, that adding roles adds to the number of columns in a data table that displays roles. Adding 8 or 9 roles to the system may be something you're interested in doing but if you do so keep in mind that you will almost certainly "double line" your data tables and/or break layout. There's only so much screen space available, keep this in mind when adding new roles to the system. * There has been a bit of a change to column visibility settings for Role and Class displays on data tables where roles and/or classes are displayed (raids view, locations view, etc.). The record in the column headers table is now @role or @class, this is a placeholder column header for ALL roles or ALL classes. Hiding the @class line in the column headers for a given data table will hide ALL CLASSES from being displayed in the data table, same for roles. There is no way to do anything else. With the changes to the system to dynamically add or remove classes or roles it is impossible now to create a column header in the table for EACH class or role in the system. Thus they're either ALL displayed or NONE are displayed. * Raid / Location limits changed to a lookup table as well. This has caused the need for a translation program to migrate data from prior versions of WRM to the newest version. This has changed to support an unlimited number of classes or roles in the system. * Selection of Talent Specs instead of Overall "Role". Another major change is the way "Roles" are assigned to WOW Character classes. In the class_role table (a new cross reference table in WRM 4) we are now listing class (Priest, Rogue, Warrior, etc.), subclass (Talent spec: Discipline, Subtelty, Fury, etc.), and then linking those talent spec declarations with a role_id, the role ID is then linked in the roles table with a role definition (Tank, Melee, Ranged, Healing, etc.) So, "Priest" in the class table will have a line in the class_role table listing Priest:Discipline, Priest:Holy, and Priest:Shadow. On the same line, Priest:Shadow may be identified as role3, while both Priest:Holy and Priest:Discipline will be linked with role4. In the roles table there will be a record with an identifier of "role3" listed as "Ranged" and an identifier of "role4" listed as "Healing". Thus, the Priest class has 2 "Healer" roles (Holy and Disc) and one "Ranged DPS" role (Shadow). In Raid View (view.php) then, when the class is drafted into the raid the selected talent spec will determine where in the list the draftee falls and what overarching role that player fulfills. A player with their spec listed as "shadow" when drafted will automatically draft into the "Ranged" role. This is a change from the pre 4.0 days where a priest selected "ranged" or "healing" from the dropdown. This provides a more rigid locking of classes to roles. On the upside, you can no longer get a priest who accidentally selects "tank" as their role (mis click or being stupid), but on the downside classes with cross specs (for instance Druids with Feral:Cat and Feral:Bear) have a harder time managing their classes. All this said, according to my sources this is actually a BETTER, more representitive way of selecting role. Feral:Cat and Feral:Bear have similar but not exactly the same talents that they take. Those specing down Feral:Cat really are not as well suited to tank as those specing for tanking, and visa versa. Again, according to my sources, this is the same with all classes. Thus requiring selection of talent spec instead of just overall role creates a better definition of what that player's capabilities are than just saying "tank". Keep in mind that because this is implemented in a "lookup" table, making modifications or adding specs is not an issue. For instance you will see in the installed table for this version that druids have *4* specs they can choose from in their dropdown lists (Balance, Restoration, Feral:Cat, and Feral: Bear), and DKs have two different specs in each of their three tress to choose from (Blood: Tank, Blood: Melee, Unholy: Tank, Unholy: Melee, etc.) Again, the data design is such that you can feel free to tweek this to your guild's extent. Add specs, remove specs, add different names for hybrid subclasses (talent specs), whatever. For instance, you could add "HaT" as a rogue subclass which would identify a talent spec that is MOSTLY subtlety, but includes significant combat/assassination talents as well. Or one could add "Combat:Sword" which would be identified differently from "Combat:Daggers" perhaps. That said, unless there are significant differences between specs is it recommended that you DO NOT make modifications. For instance, in the Combat:Sword/Dagger example above there are very few changes to talents between these two specs...as such things like buff and debuff applications are non-existant, one spec is the same as the other. The more "junk" specs you put into this, the harder this table will be to maintain in the future. Play with this to your heart's content. Keep in mind that in an upcomming version of WRM the fact that players now have identified talent specs will play heavily into more features for raid leaders (such as identification of the buff and debuff status of a raid makeup). WARNING: Because 4.0 is a floating version at this point, and because there are MANY new features yet to come into it, heavily modifying any of the tables in this version (roles, class_role, etc.) may cause significant manual work in the future as new features and possibly more columns are added. Do play with it, and do get it organized for your guild but be careful about adding a whole bunch of new stuff to it. * Dual Spec Supported - As well as now recognizing talent specs instead of just "roles", WRM also supports the WoW 3.1 Changes to allow for dual talent specializations. Profiles have the option of selecting a primary spec (this is required) and a secondary spec (optionally) or selecting "N/A" for the secondary spec (Not Applicable, meaning the character has no significant second raid spec or has not yet purchased the secondary spec ability for that character). * Drafting by Spec (Raid Lead/Raid Admin). WRM now also allows for raid leaders or raid admins to draft players according to their primary/secondary specs. As a player you will sign up to a raid and select (via dropdown) a spec you wish to play (generally your primary spec). When the raid lead goes to draft you into the raid, they may CHANGE your spec between your primary and secondary spec at will. When you are then drafted, you will see which spec you are being requested to play by the raid lead and can come prepared to play that spec. So for instance, lets say a guild Warrior is a primary spec Protection, secondary spec Fury, and generally plays a Tertiary (3rd) tank role in a raid. The player signs up for a malygos raid with "Protection" selected as his or her talent spec. For something like Malygos where a third tank is not generally needed, the raid lead would change this dropdown to "Fury" to identify to the warrior that his tanking services are not needed but that he should prep himself as a fury warrior for the raid. He would then draft the warrior and the warrior would now take up a spot in the MELEE pool, NOT the TANK pool. On the warrior's drafted record in the "Melee" section of the raid view we would see "Protection: Tank" under the "Pri Spec" column and "Fury: Melee" in BOLD under the "Sec Spec" column. This allows the raid lead to understand that the player COULD be undrafted and re-drafted to fill a tank spot if needed as well as letting the warrior know that his expected role for the evening is Fury. * Ulduar Raid Added: Ulduar is now a valid raid for selection, location creation, and addition to both locations and raids. A new icon for both 10 and 25 man versions has been added and the database updated to support the new Ulduar raid. * Migration of Data between 3.6.x and 4.0 and 3.9.9.x.x and 4.0 Created. While I swore I wasn't going to do it, I have. There is now a migration path created for upgrade between 3.6.x (release) and 4.0 as well as the 4.0 Beta releases (4.0 beta 1, Release 2) and 4.0 final. PLEASE FOLLOW THE INSTALLATION INSTRUCTIONS. Understand that the upgrade/migration has been only partially tested (3.6 -> 4.0 has been run a couple times, 3.9.9.x.x -> 4.0 has not been run at all) and that using these upgrade scripts requires knowledge of editing and changing SQL queries. There is no "automated" way of upgrading between 3.6 and 4.0 or 3.9.9 and 4.0, if you are uncomfortable running these scripts or don't know what you're doing, or have problems during running them, you are MOSTLY on your own to fix them. I will give what support I can but I will not walk you through the basics. If you are not comfortable or not able to migrate, install from scratch...this is a fully supported method of running 4.0. -- 4.0 Beta 1 Changes. * Table Views and Column Changes The largest thing that any user will experience with this new version of the software is that all tables (like the raid list, roster, users list, etc.) in the output are now generated a different way. We are no longer using the underlaying reports.php file and this, along with the Smarty Templating system's power, has allowed me to do some things with the table views we weren't able to before. First and foremost is the number of records per page / pagination. There is now a config option in the config table for Number of Records per page. If you want to limit the number of records displayed on tables to 10 instead of the prior 25 you can now do so. Keep in mind that there is no "UI" surrounding changing this at the moment. You will need to go into your config table and find the "records_per_page" config value. It should be set to 25 by default. Change that to any vaule you'd like and make sure it all works. I have been playing with 4 as a default number during my testing to ensure jump tables and the rest of the pagination stuff works. Next, the columns in each table view are now configurable as to whether they are shown or not shown, and adding new columns to a table is more "dynamic" (though will still require data values to be added to the code). There is a new database table included with this version called "column_headers" and it contains a record for each column in each view (view information listed below). Don't want to see the arcane resistance value for a drafted member of the raid anymore? No problem, turn the column visibility flag in the database off for that specific view and arcane will magically dissappear at the next page reload. Again, there is no UI associated with this at the moment (again there will be), so you will have to manually modify the visible flag for each column in the database manually...but this should be a hell of alot easier than having to go into the code and manually comment out add column lines to hide a column, and will allow admins to get the look they want out of their tables without having to suffer with default views. * Adding More Data to Each Table Output At the moment, ALL FIELDS for ALL TABLES are turned on. What you see in each table represents the MAXIMUM amount of information each table can display. If you do not see a column now, that column is not available to be shown in the view. One thing I'm looking for is suggestions for what can/should be ADDED to each of the view sets to allow more information to be shown in the various tables. The focus by most users has always been removing data they don't want to see, but I also want to make sure that any piece of information the user could possibly need on a given table in WRM COULD be displayed if they so wanted it (Within reason). As you are going through the software please keep in the back of your mind the question "Could more data be added to this table to make it more useful?" * Separating / Combining Table Outputs By and large, almost every table view in 3.6 of WRM has been separated in to it's own "view" in the column_headers table. As you are going through the application if you find places where two tables are based off of the same view and you'd like them separated, or if you find places where you really think the two views should be consolidated, please feel free to comment. * Default Column Visibility Along this same lines, if you feel any specific fields in the output should, by default, be turned off (remember they're ALL on right now), I would be willing to hear your comments on this as well. * Smarty Template System As I've hinted at and stated many many times we are now using the smarty templating system (http://www.smarty.net) as our templating system backend. One of the benefits this system provides is the ability to turn on and off debugging information for each page load. This will assist with displaying page variables and their values and give me some idea when something goes wrong as to what might be an issue. The smarty debugging symbols are ON BY DEFAULT in this and all future sets of beta code. I would request that if at all possible you leave this debugging information on while you are testing the application so that we can get information on what might be going wrong. That said, if you have non-techical users using this beta software, especially if you opt to use this as your guild's major installation, there's a high likelyhood that the debug box that pops up on page load will at minimum get very annoying and at most scare the [censored] out of your users. This can be turned off by opening the common.php file (from your WRM Root directory) and look down around lines 135. You will see a comment noting turning on and off Debugging. Please Uncomment the debugging false and comment the debugging true. DO NOT DELETE THE TRUE LINE COMMENT IT ONLY. This way, when I ask you to turn debugging back on to solve an issue, you won't have to ask "how do I do that?" Consider this annoyance my guarantee that all of my beta testers read this message, and grin to yourself every time you see a "how the hell do I turn that [censored] popup window off" secure in the knowledge that that person didn't read this message. :) The second item of interest are on lines 133 and 134. Note that Smarty has the abilty to cache it's templates for faster reload from disk. HOWEVER any template that is cached doesn't seem to re-generate itself unless the page itself changes, NOT JUST THE PAGE DATA. In other words, adding a new raid to the system will cause the page to simply reload from cache and will not flag the page as changed, thus the new raid won't show up. I have a couple ideas on a way to implement a cache mangement system for WRM, but if anyone out there in the community has experience developing applications using smarty and has a thought out plan for how to implement a cache system I would be deeply appreciative of hearing about it. Please start a new thread and let me know your ideas. -- 4.0 Beta 2 * Table / Datastructure Reorganization - Massive reorganization of the table/data structure model release allows most of the system now to be database driven. Classes, Races, Roles, and all of the rest of this inherent data is now compiled and configured in the database. This leaves the system open for expansion to other games much more easily than it was before. It also allows for some VERY cool functionality to be added based up on class, subclass (talent spec) and role. * phpArmory 0.4.2 Implemented, Cached Data implemented. A new version of the armory pull software has been added to the system. This version however is php5 compatable ONLY, php4 folks will miss out on all of these new features, but the old phpArmory system is still in place so all prior functionality should (for the moment) work without a hitch. There is a new configuration item allowing caching to database, file or no caching. * Role Changes. A new table (wrm_roles) has been added to the system allowing roles to be table configured instead of just hard coded. This allows more than the 6 default roles to be added. Simply add a role to the roles table with a sequential role ID (role7 is the next ID to use) and in the lang_index field add the lang file index name for the role text (If you have $phprlang['configuration_role5_text'] = "Role 5"; then "configuration_role5_text" is the lang_index). The configuration section will now update and modify the roles table, the role1_text-role6_text configuration items in the config table are now extranious. Table/View Name and Pages Relations -------------------------------------------- Page/Section of WRM DB View Name Comment/Position of Table Announcements announcements1 Announcements Table at the Top DKP dkp1 Main Table in the DKP View Guilds guild1 Guilds list at the Top Index (Main Page) index1 Upcomming Events AND Previous Events (Same View) Locations location1 Saved Locations Section Missing Signups (Link from Raid View) users1 Users View in the Missing Signups Link Permissions permissions1 Permission Sets List Permissions permissions2 Users List for Permission Set (click into specific permission link) Profile char1 Characters List at the Top. Profile raids1 Raid Participation List in the Middle Raids raids1 List of Upcomming Raids and List of Previous Raids Roster roster1 Main Guild Roster List Teams Link team1 Remove Users from Team Section Teams Link team2 Add Users to Team Section Users users1 User List in Main User Page Users char1 Character Details List by Clicking on Username Link in Users Raid View (By Role/By Class) raidview1 Drafted List in the Drafted Section (either by class or by role) Raid View (By Role/By Class) raidview2 Queued/Cancelled List in the Queued/Cancelled Section phpRaid_data.lua file Update ------------------------------- Template Changes ------------------------------- These are simply too numerious to list. The ENTIRE set of templates has been re-written using the smarty template system. There is NO prior template that will work with this version at all. Make sure to reset back to what is now called "default" to make things work. Unfinished/Incomplete ---------------------- * Starting Day is set inside the calendar file, not as a dropdown in configuration. To change the "first" day of the week, you need to modify the calendar. On line 100, change the word "Sunday" to the localized name of the day of the week to start on (the only two supported days are "Sunday" and "Monday" at the moment.) * CMS Bridges supporting password changing should not be a variable in the bridge but should be a configuration option. At this point, however, to turn on password changes for bridges you will need to modify the /auth/*.php file related to the bridge you have installed.