Zikula Community

• **unknown user**
  
  

  • Rank: Senior
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 2330

  Posted: Dec 12, 2007 - 11:20 AM

  Hi everyone,
  
  Long time, no type ... I know ... but I'm still around. ;)
  
  With the release of PN.8-RC2, there was a need to revisit the PostNuke Recovery Console to ensure that it worked as expected. It worked well with the RC version, but a few tweaks were needed. Isn't that always the case... ;)
  
  Code amendments:
  

  • 1) Modules module repair utility - removed.
    
  • 2) Disabled site enabler utility - removed.
    
  • 3) Permissions recovery utility - text corrections.
    
  • 4) Added version info and cleaned up 'about' page.
    

  
  
  So...that about wraps up the update... these few edits in, the Recovery Console has been re-QA'd, if you will, and is performing its tasks without failure.
  
  However, there are 2 errors at the bottom of any given view that need to be resolved before I can release it as a stable application (for PN-RC2)... they are as follows:
  
  

  Code

  Dictionary driver 'includes/classes/adodb/datadict/datadict-mysql.inc.php' not available
  
  Fatal error: class 'SafeHTML' not found in C:\xampplite\htdocs\PNRC2\system\SecurityCenter\pnuserapi.php on line 473

  
  
  ...and here's where I need the advice... I'm looking for the best (quickest, slimmest) way to remove these messages, but to do so in a proper "PN way".
  
  Any suggestions would be appreciated!
  
  Thanks much for RC2!!
  
  - John

  • 
  •  
• rgasch
  
  

  • Rank: Team Member
  • Registered: Jan 05, 2003
  • Last visit: May 28, 2010
  • Posts: 775

  Posted: Dec 12, 2007 - 11:53 PM

  Hi,
  
  there isn't an API for this, but the following should do (but that will clear out *all* such messages):
  
  

  Code

  SessionUtil::delVar('_PNErrorMsg');
  SessionUtil::delVar('_PNErrorMsgType');
  SessionUtil::delVar('_PNStatusMsg');
  SessionUtil::delVar('_PNStatusMsgType');

  
  
  The real question though is *why* are you getting these messages?
  
  Greetings
  R

  • 
  •  
• **unknown user**
  
  

  • Rank: Senior
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 2330

  Posted: Dec 13, 2007 - 01:26 AM

  Thanks Robert,
  
  As you indicated, the real question is why... Since the error didn't exist in the previous version of the Recovery Console, my guess is that RC2 introduced it....(some super-sleuth huh!) ...I tried various fixes to no avail. Ideally, the fix will not rely on deleting session variables, but rather on solving the actual problem. I can't figure out why these messages persist. If I'm unable to clear these up at the source, your suggestion will be the course of action.
  
  Any additional thoughts are appreciated; I can provide a copy of the amended Recovery Console if that would be of any use.
  
  Thanks,
  
  - John

  • 
  •  
• **unknown user**
  
  

  • Rank: Senior
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 2330

  Posted: Dec 15, 2007 - 08:27 AM

  Found a solution:
  
  ...in the pnADODBInit() function (RC2)...
  
  
  changing this:
  
  

  Code

  if (!defined('ADODB_DIR')) {
          define('ADODB_DIR', 'includes/classes/adodb');
      }

  
  
  
  to this instead:
  
  

  Code

  if (!defined('ADODB_DIR')) {
          define('ADODB_DIR', getcwd(). '/includes/classes/adodb');
      }

  
  
  
  ...fixed both errors.
  
  Thanks for looking at this.
  
  - John

  • 
  •  
• kaffeeringe.de
  
  

  • Rank: Software Foundation
  • Registered: Sep 03, 2002
  • Last visit: May 09, 2010
  • Posts: 909

  Posted: Dec 16, 2007 - 12:37 AM

  Oh nice! I found the same error in Jörn's "Content" module
  
  --
  best regards from Kiel, sailing city
  
  Steffen Voss
  
  Member of the Zikula Steering Committee
  Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"

  • 
  •  
• kaffeeringe.de
  
  

  • Rank: Software Foundation
  • Registered: Sep 03, 2002
  • Last visit: May 09, 2010
  • Posts: 909

  Posted: Dec 16, 2007 - 12:52 AM

  When I fix the pnAPI.php Content displays "Fatal error: Class 'ADODB_BASE_RS' not found in /www/htdocs/includes/classes/adodb/adodb.inc.php on line 2714"
  
  --
  best regards from Kiel, sailing city
  
  Steffen Voss
  
  Member of the Zikula Steering Committee
  Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"

  • 
  •  
• larsneo
  
  

  • Rank: Software Foundation
  • Registered: Dec 31, 1969
  • Last visit: Oct 21, 2009
  • Posts: 3814

  Posted: Dec 16, 2007 - 12:57 AM

  due to some problems with getcwd() (see manual entry at php.net) i'd suggest to use
  
  

  Code

  if (!defined('ADODB_DIR')) {
          $cwd=str_replace($_SERVER['SCRIPT_NAME'],'', $_SERVER['SCRIPT_FILENAME']);
          define('ADODB_DIR', $cwd. '/includes/classes/adodb');
      }

  
  
  --
  regards from germany
  ..::[Zikula Application Framework]::.. ..::[SEO-Blog]::.. ..::[CMS Sicherheit]::..

  • 
  •  
• kaffeeringe.de
  
  

  • Rank: Software Foundation
  • Registered: Sep 03, 2002
  • Last visit: May 09, 2010
  • Posts: 909

  Posted: Dec 16, 2007 - 12:57 AM

  If you do it - do it right. I didn't apply the fix correctly. Now the error is gone (and a "Content"-error shown )
  
  --
  best regards from Kiel, sailing city
  
  Steffen Voss
  
  Member of the Zikula Steering Committee
  Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Dec 16, 2007 - 09:20 PM

  The problem seems a little deeper than this. I can't see why yet but something is screwing around with the working directory.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• Topiatic
  
  

  • Rank: Expert
  • Registered: Nov 23, 2003
  • Last visit: Dec 13, 2009
  • Posts: 1487

  Posted: Dec 17, 2007 - 09:35 AM

  Add RosterMaster to the module list producing this error.
  
  --
  Under Construction!

  • 
  •  
• Topiatic
  
  

  • Rank: Expert
  • Registered: Nov 23, 2003
  • Last visit: Dec 13, 2009
  • Posts: 1487

  Posted: Dec 17, 2007 - 11:17 AM

  Topiatic

  Add RosterMaster to the module list producing this error.

  
  
  In other testing I discovered that module vars for third party and upgraded system modules do not get serialized during upgrade. To fix this I changed function pnModGetVar() at line 104 - 107 from:
  

  Code

  foreach($results as $k => $v) {
              $pnmodvar[$modname][$k] = @unserialize($v);
          }

  
  To:
  

  Code

  foreach($results as $k => $v) {
              if (!$pnmodvar[$modname][$k] = @unserialize($v)) $pnmodvar[$modname][$k] = $v;
          }

  
  
  And it solved a lot of reported issues for me including this one, could this be the root of the issue?
  
  
  --
  Under Construction!

  • 
  •  
• JørnWildt
  
  

  • Rank: Softmore
  • Registered: Jul 02, 2002
  • Last visit: Oct 21, 2009
  • Posts: 240

  Posted: Dec 22, 2007 - 03:14 AM

  I have also seen this problem a couple of times - but ONLY in situations where other modules have an error. When it happens during development I have found out that I need to look at my own code first - when I then fix my bug, the ADODB issue goes away.

  • 
  •  
• **unknown user**
  
  

  • Rank: Senior
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 2330

  Posted: Dec 22, 2007 - 06:46 AM

  Thanks for the input guys.
  
  Jorn, in the case of the Recovery Console (PNRC), at my last testing only core modules were installed, and it was tested on a "pristine" installation of the RC2 package with absolutely no tweaks, additions, or subtractions. I understand the importance of looking at our own code, but don't think that's the issue here, since the problem has only sprung up (across the board, it seems) with the new RC2 package.
  
  In the new version of the Console, which is designed simply for RC2 usage, only very minor changes were made to the application code...none of which had to do with paths, urls, or file locations (see first post of this thread). The changes were very elementary in nature and I have scrutinized the code numerous times, very carefully and using E_ALL strictly throughout development; the application contains no errors or warnings (via Eclipse's notifications, which are also strictly set), except these 2 new errors in question.
  
  The fact that so many applications are _now_ experiencing this same issue would point toward a core change that caused this issue, IMHO...unless we all made the same "change(s)" to our apps at the same time, which seems extremely unlikely.
  
  Since I'm not dev'ing PN modules much anymore, the Recovery Console is the only place that _I_ am having this issue, but since many others are having this same problem, a careful look at the core would be more in order than for all devs to re-look at code that has worked all along without issue.
  
  I'm perhaps luckier than some in that since the Recovery Console is nearing obsolescence, this issue will soon be moot from my seat, perhaps by RC3 or .8 Final, even.
  
  Again, just trying to keep the app up to date with PN releases. The application does still perform the tasks it is designed to...my primary concern is in that if the Recovery Console app is dirtied by onscreen errors/warnings, it cannot be released, even if it does in fact work. It's a personal preference relating to QA, I guess; we all want our work to shine, if you will, no matter the scale of the project.
  
  I would be happy to post/send the amended application to anyone who would be willing to look at it. It is a single file of approximately 2000 lines, half of which are code comments, and fully OO'd for better compartmentalization.
  
  Any takers!?
  
  

  • 
  •  
• JørnWildt
  
  

  • Rank: Softmore
  • Registered: Jul 02, 2002
  • Last visit: Oct 21, 2009
  • Posts: 240

  Posted: Dec 23, 2007 - 08:50 AM

  Alar:

  Quote

  I understand the importance of looking at our own code, but don't think that's the issue here, since the problem has only sprung up (across the board, it seems) with the new RC2 package.

  
  
  Sure - I think you might have misunderstood me - I was saying this to indicate that the problem is in the core, not in our code, and it might be in the error (warning?) handling since the error occurs when some other code initiates another error.
  
  Besides this I have also noticed that using exit(0) in the code causes my PHP (4.3.1) to deliver a Blank Page, whereas pn_exit(0) works. This might although just as well be a problem with pnForms since I use that on all the involved pages. Have anyone experienced this - for instance during debugging where your dump some data and then exists?

  • 
  •  
• Simon
  
  

  • Rank: Legend
  • Registered: Dec 11, 2002
  • Last visit: Oct 21, 2009
  • Posts: 11674

  Posted: Dec 23, 2007 - 11:04 AM

  You need to call pnShutDown in .8 before terminating execution. I've come across that problem before..
  
  --
  itbegins.co.uk - Zikula Consulting
  
  birtwistle.me.uk - Personal Blog
  
  
  Please read the Support Guide

  • 
  •  
•  
•  

Users on-line

• 0 users

This list is based on users active over the last 60 minutes.