21
RVirtue
Re: 2.7.3 to 2.9.2 upgrade - extra/login.php
  • 2005/1/4 11:06

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


It's only needed if your site is using SSL. For instructions, ya hafta look inside the file itself:
// This script displays a login screen in a popupbox
// when SSL is enabled in the preferences. You should
// use this script only when your server supports SSL.
// Place this file under your SSL directory
Don't feel bad. If you think XOOPS makes some things obscure, try figuring out Xaraya.



22
RVirtue
Re: where's the 2.0.9.1 news topic gone?
  • 2004/12/30 15:33

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


Methinks I'll wait 'til it's official. I wonder if this one will have a "certificate" from the new QA team.



23
RVirtue
Re: where's the 2.0.9.1 news topic gone?
  • 2004/12/30 15:00

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


Thank you, onokazu. I think that answers the question I was trying to ask, but perhaps failed to express clearly enough. I wasn't worried about replacing the XOOPS installation files themselves as many times as might be necessary. My concern, while waiting for an "official fix", was about any possible risk of site data corruption due to glitches in the previously posted and installed patches and, if so, how best to handle it.



24
RVirtue
Re: where's the 2.0.9.1 news topic gone?
  • 2004/12/30 14:03

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


Hmmm. Since Xmas, I've updated both my XOOPS installations (test and production sites) from 2.0.7.3 through the 2.0.9.0 and 2.0.9.1 patch series as previously posted. Does this mean that I need to go back and start over?



25
RVirtue
Re: Error [Xoops]: Unable to connect to database in file class/database/databasefactory.php line 34
  • 2004/12/15 16:54

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


Hi. I'm adding my "two cents" here at James' request, but I'm not sure I can be very helpful in pinning anything down.

I too have seen here the error noted in this thread's title. It has caused me to lose my "inputs" often enough, in fact, that I'm now more careful than ever to prepare and save messages and replies off line prior to any posting attempt. However, I would also have to say that any relationship to other issues, such as those involved in our Netquery development work, is tenouous and unproven.

In developing the Netquery module, we ran into several problems that appear to have been involved simultaneously and, at the time, I was much more concerned about eliminating the difficulties than I was about causal relationships. Thus it is difficult to attribute specific aspects of those problems to a particular cause. The best I can do is to list some factors:

1) The XOOPS module installer appears to have some difficulties with handling some phpMyAdmin exports, especially large ones. Version specificity may be involved as with, for example, the recent change in phpMyAdmin's comment character.

2) It appears that some hosting service providers (my 1and1.com "business package" host for sure) are imposing their own "unadvertised" restrictions on SQL queries. Even their senior support staff may be unaware of these restrictions which, in the case I now know about, limited data inserts to about 2000 records each.

3) Host configuration settings for both PHP and MySQL can also be involved and may or may not be capable of being overridden by individual accounts with either .htaccess or php.ini local settings. PHP script timeout is mentioned briefly in "carnuke's" excellent FAQ, but there are others as well that can be significant for data handling ops.

That's about as much as I can say with any certainty about the situations I have encountered myself. Hope it helps to at least open some routes for further exploration.



26
RVirtue
Re: Moving to new host - mysql database problem
  • 2004/12/15 15:48

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


In the .SQL dump file that you posted in your opening message, the following lines were created by the phpMyAdmin export process as informational comments:
-- phpMyAdmin SQL Dump
-- version 2.6.0-pl3
-- http://www.phpmyadmin.net
-- 
-- 
Hostlocalhost
-- Generation TimeDec 142004 at 12:26 PM
-- Server version4.0.22
-- PHP Version4.3.9
-- 
-- 
Database: `docuwedd_docuwedd`
-- 
-- --------------------------------------------------------
-- 
-- 
Table structure for table `xoops_avatar`
-- 
-- 
CreationFeb 012004 at 05:59 PM
-- Last updateDec 142004 at 11:28 AM
-- Last checkDec 142004 at 11:28 AM
--
Those comments have no operational purpose and can be deleted or, using any plain text editor, you can replace the comment characters (change -- to #) at the beginning of each line.

I've seen the XOOPS module installer "choke" if the newer phpMyAdmin v2.6.x comments are included in the .SQL file that it uses. (It appears to expect the older # comment character.) But this is just a suggestion for you to try. I don't know enough details about the exact process you're following to offer any "guaranteed" solution.



27
RVirtue
Re: Doing very large DB updates
  • 2004/12/14 15:47

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


While the FAQ is good as far as it goes, I'm not sure that its backup/restore advice fully addresses this user's situation. And, unfortunately, when it comes to adding a large amount of new data to a database, the potential issues are manifold.

In addition to the default PHP timeout (30 seconds) mentioned briefly in the FAQ, I've also found (after much head banging) that some service providers impose their own "unadvertised" restrictions on SQL queries, even for so-called "business package" accounts. In fact, my experience also suggests that the XOOPS module installer itself is not without a few quirks of its own when it comes to handling new SQL dB additions that are larger than "normal".

Basically, there are two "workaround" approaches. The first involves using a l-o-n-g series of single record inserts. The phpMyAdmin utility can be made to export data that way if one unchecks its "extended" option. Alternatively, one can split the large insert into smaller "chunks". (In my own case, approximately 2000 records each seemed to satisfy the limits imposed by my service provider, but others may vary, of course.) The latter approach looks something like this:
$query = ...
(
02018'tcp''terminaldb'''0), 
(
02018'udp''rellpack'''0), 
(
02019'tcp''whosockami'''0);"; 
$result =& $dbconn->Execute($query); 
$query = "INSERT INTO ".$PortsTable." VALUES 
(03050'udp''gds_db''gds_db'0), 
(
03051'tcp''galaxy-server''Galaxy Server'0), 
(
03051'udp''galaxy-server''Galaxy Server'0), 
...
$result =& $dbconn->Execute($query);


Hope that helps.



28
RVirtue
Re: Moving to new host - mysql database problem
  • 2004/12/14 14:23

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


rudycash:

Is it possible that the export/import involves two different versions of phpMyAdmin. If so, I've noticed that the comment character change from single octothorp (#) to double dash (--) somtimes seems to confuse older versions. Getting rid of the intial comments in the .SQL file (or changing them back to the older comment character) prior to importing might be worth a try.



29
RVirtue
Re:Stalled installation
  • 2004/11/4 15:56

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


This is utterly and maddeningly ridiculous!!! And I am really begininning to lose my patience with the damned thing entirely.

It's not the XOOPS core. It's the blankety-blank XOOPS module installation/update handler. It's totally f***ed up, and that is NOT just a guess. Here's what I've done.

1) I have built a function capable of being called and run from Netquery's own admin panel inside XOOPS using XOOPS core functions to build and populate the dB table in question.

2) Running that fuction works perfectly, creating and populating the table (all 10528 port lookup items with 5 data fields each) within just a few seconds and without a whimper.

3) I then used phpMyAdmin to export the same table just created and added the exported dump to the mysql.sql file that XOOPS uses to initialize the Netquery module.

4) On uninstalling and attempting to re-install the Netquery module with the datatable that XOOPS itself had created, it locks up (white screen) as before.

You can probably tell that I've reached a certain level of frustration. In fact, I'm about ready to say to hell with it and instruct XOOPS users to build that datatable themselves when they first install or update the module using the Netquery admin fucntion that does work. I'll post an "X" version and let you try it.

Richard.



30
RVirtue
Netquery MultiWhois? - Development Input Request
  • 2004/10/31 17:16

  • RVirtue

  • Quite a regular

  • Posts: 246

  • Since: 2004/8/4 9


My Netquery Project partner, JMorris, has suggested that enhancing its Whois feature to permit multiple simultaneous lookups ("MultiWhois") might be of interest for web hosting and related purposes. This is to request wider input on that suggestion to assist me in guaging the level of actual interest. Keep in mind that each Netquery feature can be enabled or disabled by the site administrator.

I have have done some very preliminary work based on the standalone (SA) version of Netquery to permit assessment independently of any CMS. But the concept is just as easily applied to any of the CMS modules.

As an initial basis for comment by anyone interested, I've uploaded a SA_NETQUERY_X package athttp://users.vianet.ca/rvirtue/tools/ It is crude, unpolished and currently limited to only three (3) simultaneous whois lookup requests. (The X stands for experimental and the coding, while fully functional, reflects that stage of development.) Before taking it any further, I wanted to get some initial reaction and feedback on the general concept.

As usual, the only difference between the .ZIP and .TAR.GZ downloads is that the former is preconfigured for Windows while the latter is preconfigured for UNIX/Linux systems. But either one can, of course, be reconfigured -- not that it matters as far as the MultiWhois feature is concerned.

Regards to all,
Richard Virtue




TopTop
« 1 2 (3) 4 5 »



Login

Who's Online

269 user(s) are online (158 user(s) are browsing Support Forums)


Members: 0


Guests: 269


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits