Currently I down load from the IA website to my local machine and then have to upload to my server.  It would be nice to save the initial step.

Thanks

Glen

I also checked the 3.55 beta version and it isn't fixed there yet.

The error only applies to MariaDB users not MySQL users.

MariaDB's last version 5 release was 5.5.5. (below the required 5.6 for cmsb 3.54)

Next major version is 10.0 and current version it 10.5.

mysqli()->server_info returns "5.5.5-10.5.9-MariaDB" and after IA's regex is applied we get "5.5.510.5.9 " and fails because it is still less than 5.6

This is how I fixed it and maybe will give IA an idea on how they want to do it.

File: cms/lib/menus/admin/general.php Line: 76

  ### SHOW OLD PHP/MYSQL WARNINGS
  $currentPhpVersion   = phpversion();
  // $currentMySqlVersion = preg_replace("/[^0-9\.]/", '', mysqli()->server_info);  // replace chars, not numbers and dots.  Returns: 5.5.510.5.9
  /* gma */
  $cVer = mysqli()->server_info;
  if(stripos($cVer,"MariaDB") !== false){
    $cVerArr = explode('-',$cVer);
    $currentMySqlVersion = (count($cVerArr) > 2)? $cVerArr[1] : $cVerArr[0]; // returns 10.5.9 or 5.5.65 
  }else {$currentMySqlVersion = preg_replace("/[^0-9\.]/", '', $cVer);}      // else use IA's method
  // echo $cVer." ======== $currentMySqlVersion";

An intermediate solution.  I think IA's final solution will likely have to have 2 versions numbers to compare since MySQL and MariaDB versioning are now out of sync.

Food for thought.

This is my very old ITIStudios testing server that is about to be retired in a few weeks or so.

It's a win 2000 Advanced server running IIS ( IIS 5 I think?).

The php (v5.2.17) and the mysql (v5.0.51) versions are not compatible with the newer CMSB versions and didn't bother to mention it because it's not a flaw with 2.65

In the php.ini file "Notify" is part of the error reporting and may be excluded on production servers which could be why you haven't see this before.

The error only occurs when you login and logout otherwise everything is fine.

That being the case we still don't want to log it as an error when it's not.

As part of the test I added this code at line 104

if (isset($_SERVER['QUERY_STRING'])) echo "QUERY_STRING is set"; else echo "QUERY_STRING is not set";

Just to clarify:

When the page loads for the first time "it is not set"

After entering the login credentials and click the Login " button "it is not set"

Normal navigations if fine "is set"

When you click the "logoff" link, "it is not set" (but this is really the same as when the page loads for the first time)

I performed a fresh install of Beta v2.65 this morning and encountered an unnecessary error being logged.

E_NOTICE: Undefined index: QUERY_STRING

xxxxxxxxxxxxxxxxxxxxx\lib\common.php (line 108)

xxxxxxxxxxxxxxxxx/admin.php

You could just suppress it I suppose but I'm not a big fan of suppressing errors.

Line 108: if (sha1($_SERVER['QUERY_STRING']) == '3831b0376dab413292f03dd30523e749bdd3279e') {

A suggestion:

if (isset($_SERVER['QUERY_STRING']) && sha1($_SERVER['QUERY_STRING']) == '3831b0376dab413292f03dd30523e749bdd3279e') {

In "Admin > General Settings", in section "Regional Settings"

Selecting the check box after "Developer Mode" for "Automatically add new language strings to language files" does not initially work as expected.

In order to get it to work for a plugin I'm currently writing, I found that you have to select a language other than "Default" from the drop down "Program Language" list.

To save others a little grief, you might want to add a note, something like what I have shown in red:

Developer Mode     [ ]     Automatically add new language strings to language files [ select a language other than "Default" from the drop down "Program Language" list ]

Also, it will not update the plugin language files if the "Program Language" selection is set back to "Default".

Consider adding a note or two in the "how_to_add_languages.txt" about this which would help to get it working quicker.

I think my suggestions would have saved me some time figuring it out.  A Nice feature but a little tricky to figure how to use it.

Just a suggestion.

Update:  A better solution might be to allow "Default" to select one of the users installed languages and error message if there aren't any installed.

I was already using the "'menuHidden'" key in the plugin_activate/deactivate hooks which addressed the user input issues.

I was not aware of that schema key ''tableHidden'' which addresses my concerns in the section editor, thanks for  bringing that to my attention.  I've tested it and that works perfectly.

I don't think this will need to be a system plugin with the use of the keys mentioned above.

After entering the plugin file name in 'Required Plugins'  it didn't do any thing.  But I suspect it would if I required a plugin other than 'itself".  The two keys above do the trick so I won't pursue this.

I now understand how the "Required Plugin" works. It adds a little insurance but as with the keys, if the user manually edits the schema file we've lost control anyway.

Thanks for the tips.

Since writing the post, I believe I have found a better and more appropriate solution to my issue.

Basically I want to change the menuNames and set warnings in the interface if the plugin isn't activated. I can't have the end user modifying table data if the plugin isn't active since a lot of the input data is in hidden calculated fields.

I'm just in the process of testing the use of hooks "plugin_activate and plugin_deactivate".  These appear to be far more appropriate for what I am trying to achieve including the hiding the tables altogether (when not active).

Anyway, with all the code review and investigation I had done, there is no way (that I could find) to do any customization to the "Edit Field" dialog since the call to loadSchema() is just prior to showing the dialog content. I was mainly looking at the schema data not any of the global vars.

So, although it does look like I will need the hook I was asking about I still think it might be a useful hook for some thing else in the future.

My post should be revised to "A good place to add a hook" !

Thanks for getting back to me so quick.

I'm creating a new plugin and with the current "Hook" list I am able to modify the "out put" to suit my plugin except in the "Section Editors" > "table" > "Field Editor".

In lib/database_functions.php, the function loadSchema($tableName, $schemaDir = '') is called prior to the "Field Editor" opening which over rides any plugin modification I have made else where.

Adding a hook in this function would allow for easy modifications to the "Field Editor" dialogue.

function loadSchema($tableName, $schemaDir = '') {
  global $APP;
  // error checking
  if (!$tableName)                                       { die(__FUNCTION__ . ": no tableName specified!"); }
  if (preg_match('/[^a-zA-Z0-9\-\_\(\)]+/', $tableName)) { die(__FUNCTION__ . ": tableName '" .htmlspecialchars($tableName). "' contains invalid characters!"); }

  // get schemapath
  $tableNameWithoutPrefix = getTableNameWithoutPrefix($tableName);
  if (!$schemaDir) { $schemaFilepath = DATA_DIR . "/schema/$tableNameWithoutPrefix.ini.php"; }
  else             { $schemaFilepath = "$schemaDir/". getTableNameWithoutPrefix($tableName) . ".ini.php"; }

  // load schema
  $schema = array();
  if (file_exists($schemaFilepath)) {
    $schema = loadStructOrINI($schemaFilepath);
  }

  // add _tableName (v2.16+)
  if ($schema) {
    $schema['_tableName'] = $tableNameWithoutPrefix;
  }

doAction("new_loadSchema_hook",$tableName,$schemaDir);
  //
  return $schema;
}

As side from solving my plugin issue, it would seem that this is an ideal location for more advance customization due to the existence of the 2nd parameter "$schemaDir". 

Would you consider adding a "hook" at this location in your next release?

Alternatively, can you suggest a way of intercepting the output to perform modifications?

Actually, your response was so thorough I thought maybe you were feeling a need to be defensive.  That was not my intention and hope you did not interpret my questions or comments in that way.

I turned on the "useThisBetaFeature" and it "did" removed the zero byte sessions.

To you and your team, thanks for the great product.

We've been battling with PHP sessions for a while. The issues are the various web hosts servers delete them too soon, too late, or not at all. Sometimes multiple websites on the same server use the same /tmp/ folder and erase each others session files when they shouldn't, and in this latest case that you found, sometimes we have developers using other 3rd party apps that use sessions, so we've had to stop destroying the entire session or we risk erasing data used by another web app on the same server.

The difficulties with other "apps", "plugins" and "servers" makes me want to ask the question:  Are you trying to solve a problem that is "not" a CMSB problem?

The other thing I've noticed is a departure from the separation of CMSB and Plugins. 

As a user of CMSB it's my expectation that CMSB will be rock solid and stable without any "active" plugins. The current session issue makes we wonder if you are not adhering to any rules with respect to seperation of CMSB from other influences.  

Changes to your stable back end to solve a 3rd party issue I think is fundamentally wrong which, as is in the case of the current issue, has broken the back end.

For example, I've come across code in CMSB to solve/fix issues with your "Website Membership" plugin. Since the code relates to a specific plugin issue it should be in the plugin and accessed via a "Hook".

You as the developer of CMSB can add "hooks" where ever you like to address specific plugin issues for plugins you create.  Thus new versions of CMSB should only consist of new features and fixes in addition to new hooks to your already stable release.  Hooks theoretically will never break the back end.

Does IA have a design philosophy in this regard such as is the case in the philosophy of "separation of church and state" where the state is CMSB and the church is things like servers, apps and plugins?

This philosophy will ensure that CMSB can continue to be improved upon in its all ready feature rich state and remain stable. Specific issues as they relate to plugins can be isolated and worked on with breaking CMSB for those aren't using any particular plugin.

I think CMSB is fabulaous and the ability to perform customization via plugins is out standing. 

I am interested in knowing if IA has an official position on the relationship of CMSB to Plugins that I have talked about here. 

Dealing with the second item first:

  // Load last _REQUEST from _SESSION (current _REQUEST values override old ones)

Your code update does solve the problem.

As for the first issue:

function user_logoff($redirectUrl = '') {...

I am aware of this function and it was here that I discovered you had removed the session destruction.

I have also read in other recent threads you are having problems with zero byte sessions.

// 2.52 - clear saved CMS session data
  if (isset($_SESSION['lastRequest'])) { unset($_SESSION['lastRequest']); }

Your update removes the "'lastRequest'" session data but if no other session data exists it leaves behind a zero byte session which users seem to be having issues with.

Here are couple of suggestions that would help to get rid of the dreaded zero byte sessions.

In addition to your update continue to destroy the session if it is empty :

function user_logoff($redirectUrl = '') {
  loginCookie_remove();                   // erase login cookie
  $GLOBALS['CURRENT_USER'] = false;       // clear user global

  // 2.52 - clear saved CMS session data
  if (isset($_SESSION['lastRequest'])) { 
    unset($_SESSION['lastRequest']); 
    // If the session is empty after removing the CMSB 'lastRequest', then destroy it since there is no apparent value.
    if(!count($_SESSION)) session_destroy();
  }

  // redirect/refresh page

The other time a zero based session is created is when the login page is loaded.

So if you are not being redirected when you log off, the login screen appears but a zero byte session would also have been created earlier in the procedure. 

You could destroy the session at this point as well in lib/admin_functions.php

// if no logged in user
  if (!$CURRENT_USER) {

    // perform login screen maintenance actions - useful place to run common operations
    if (!$action) {
      createMissingSchemaTablesAndFields(); // create/update missing schemas, etc

      // show helpful messages
      if (!mysql_count('accounts')) { alert(t("There are no user accounts in the database.")); }
    }

    // show login screen if user not logged in
    if(!count($_SESSION)) session_destroy();  // destroy the newly created empty session
    showInterface('login.php', false);
    exit;
  }

If a user/visitor arrives at the login page for what ever reason a session will not exist until authenticated.

I've tested this in ver. 2.51 and my suggestions seem to work without any issues. 

While working on a new set of tables I clicked on a field label to change the sort order and unbenounced to me this change was stored in the session.

Later I decided to rename the field in the Section Editor  and discovered I could no longer access the table view due to this error "Can't sortBy 'acl_con'. Not a valid field!"

After a lot of screwing around I was able to figure out how to correct it:

1. Login to the server and physically delete the session but that only works if you have access to the server.
2. Return to the Section Editor and rename it back to the original name.

A person can go nuts trying to figure out how to rename a field if they don't realize they have set it as the sorting field in the table view.

Initially I thought logging out and back in would correct the problem which of course didn't work until I discovered it was due to the session.

This raises the question "why aren't sessions being destroyed"?

It is my opinion that if the user logs out that the session should be destroyed.

If it is desirable for a particular application or plugin to retain criteria that this be stored in the users cookie which can be added to the session at next login if required.

It appears to me that you may be crossing the line between session and cookie usage!

My main issue is that I don't believe a session should exist if the user "logs out".

And storing information that can disable the interface will likely become more problematic without some means of destroying the session.  You might want to consider a link in the admin section to destroy current session although I'm not sure that will solve the problem if the user isn't aware of the cause.

ITI/Glen: Thanks for your feedback. When you say you don't want to see a "user reply/counter" do you mean a specifically user titles (Newbie, Regular, Expert) based on post counts? Or showing post counts at all? Right now we don't have any plans for user titles (I don't get them either). We want to keep the base release simple, but make the aggregate data available for developers to do whatever they want with, basically creating a really solid framework that can be built on. So in theory people could add it if they really like it. If we do something like that in the future I'd be curious to check out how stackoverflow.com, slashdot, and others do it, I think there's some much more modern approaches than just post counts for titles.

I guess what I'm really saying is "anything that rewards a member based on the number of post he/she makes should be discouraged".  Members posting to anything and everything just to reach that next milestone results in all those useless "replies to posts" that I was ranting about.  I'm sure you're right in that there is a more modern approach to classifying members.

Thanks for listening

I've updated the code for the next release to use rename_winsafe (and optimized/tested that function).

It only uses the rename() overwrite functionality in common.php, so the quick fix is just to replace rename with rename_winsafe, or alternatively just upgrade PHP to 5.3 or better.

Also, note that for the next release of CMSB we're going to be upping the server requirements to PHP 5.2.4+ and MySQL 5.0+, so if you're running lower version then those it might be a good time to upgrade as well.

What PHP version and windows version are you running?

Select 'sh' is not recognized as an internal or external command, operable program or batch file. Select version to restore