I have made updates to the plug and I have a problem

Ok, I have also made this upgrade from the 1.6 version to your newest 2.0.2 release.

I am unsure of these issues, but I will address the ones I can notice, and see if anyone else has had them.

1: Variables management page: button says “load wordpress default variables”, when clicked it comes up with this message: “Please confirm that you would like to load the Joomla whitelisted variable rules”.

1A: variables page also shows a “0” ID variable, with NA listed… is this needed? garbage?

2:Virus Scanner Panel: no progression bar during scan? says virus scanning in progress but nothing moving? lack of working indication status…. oversight?

3: virus scan config page: the option for File Extensions when upgraded show slashes in teh fields like this:

\\htm\\,\\html\\,\\shtm\\,

is that correct? or should they be like this:
htm,html,shtm,shtml,css,js,php,php3,php4,php5,inc,phtml,jpg,jpeg,gif,png,bmp,c,sh,pl,perl,cgi,txt

3A: scan file size box is incorrect sizing, not editable, blank. The box exists, but is nothing there, can’t click on it at all, not accepting input.

4: Admin Email Panel: shows a 0 ID, which cannot be deleted.
4A: cannot link to anything using the add linkage. it clicks, but shows no admin user in the drop down. can try entering name, will not save

5: DATABASE SIZE
This is a big one in my book. Seems my DB has quandrupled in size by updating the plugin. Going from 500k to 2 megs is not a lot in the grand scheme but when comparing the two sql files I noticed this type of issue.

I understand adding to the DB, but are you really storing non-changing updates and drop table commands in the db itself? should these not be part of the programmatic structure within the php code?

There is a massive section of sql code all related to this plugin (seen in part below, would not save post with all of it)

--
-- Table structure for table <code>kxxp1w39s_ose_app_admin</code>
--

DROP TABLE IF EXISTS <code>kxxp1w39s_ose_app_admin</code>;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE <code>kxxp1w39s_ose_app_admin</code> (
  <code>id</code> int(11) NOT NULL AUTO_INCREMENT,
  <code>user_id</code> varchar(45) NOT NULL,
  PRIMARY KEY (<code>id</code>)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table <code>kxxp1w39s_ose_app_admin</code>
--

LOCK TABLES <code>kxxp1w39s_ose_app_admin</code> WRITE;
/*!40000 ALTER TABLE <code>kxxp1w39s_ose_app_admin</code> DISABLE KEYS */;
/*!40000 ALTER TABLE <code>kxxp1w39s_ose_app_admin</code> ENABLE KEYS */;
UNLOCK TABLES;

--
-- Temporary table structure for view <code>kxxp1w39s_ose_app_adminemailmap</code>
--

DROP TABLE IF EXISTS <code>kxxp1w39s_ose_app_adminemailmap</code>;
/*!50001 DROP VIEW IF EXISTS <code>kxxp1w39s_ose_app_adminemailmap</code>*/;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
/*!50001 CREATE TABLE <code>kxxp1w39s_ose_app_adminemailmap</code> (
 <code>name</code> tinyint NOT NULL,
  <code>email</code> tinyint NOT NULL,
  <code>id</code> tinyint NOT NULL,
  <code>user_id</code> tinyint NOT NULL,
  <code>email_id</code> tinyint NOT NULL,
  <code>subject</code> tinyint NOT NULL,
  <code>app</code> tinyint NOT NULL
) ENGINE=MyISAM */;
SET character_set_client = @saved_cs_client;

Osexcel,

Fully appreciate trying to keep aspects faster. However, this was a sql section of 1.5 megs (in total) just from this update.

No offense, many of us here are programmers, myself included. That is a considerable amount to place within the DB. Especially when only core data need be in the DB, and the sql strings can be done programmatically in the php.

I have little issue with storing the data for the queries, but find it odd to store anything more then absolutely necessary in the DB.

If no one has a copy, I suggest “Database Design for Mere Mortals” from Amazon.

I am sure that you guys are top notch programmers. As a developer myself though I do understand that sometimes things are pushed out too early because they work, not because they are clean and efficient.

The other issues I mentioned prevent me from knowing for sure if the plugin is truly working for me. The old version notified me several times daily and since I cannot get notifications with this version I have little choice but to revert back to earlier release.

As to the framework. What changes did you have to make to include such a clunky framework??? That’s where I am a little confused.

It is one thing to add a little space in the DB or even double the size of the plugin, but that one plugin doubled the entire size of the blog. This is a 30x factor increase in overall size…

Assuming the functionality remained mostly the same, and adding geo functionality, most of that size becomes the UI which should be quite unacceptable IMHO.

I truly *liked* your firewall. Had it on over a dozen blogs and was planning on dozens more, but now that is on hold.

Osexcel,

Glad I could at least help get the creative juices flowing in the right direction. Those sound like some pretty good steps in the right direction.

I will look over this version some more, but until I can at least solve these issues on my test server I will not upgrade to this versoin on a production site.

I look forward to more details.

Do you mind if I ask another question? What prompted the considerable change in format from the old 1.6.4 to the new version? Was MVC and GeoIP the only reasons?