241
Nick_James
Re: Where are the constants set?

Another 6 errors in Block Admin

Notice: Use of undefined constant _AM_CUSTOM - assumed '_AM_CUSTOM' in file /modules/system/admin/blocksadmin/blocksadmin.php line 48
Notice: Use of undefined constant _AM_TYPES - assumed '_AM_TYPES' in file /modules/system/admin/blocksadmin/blocksadmin.php line 60
Notice: Use of undefined constant _AM_GENERATOR - assumed '_AM_GENERATOR' in file /modules/system/admin/blocksadmin/blocksadmin.php line 66
Notice: Use of undefined constant _AM_TYPES - assumed '_AM_TYPES' in file /modules/system/admin/blocksadmin/blocksadmin.php line 72
Notice: Use of undefined constant _AM_TYPES - assumed '_AM_TYPES' in file /modules/system/admin/blocksadmin/blocksadmin.php line 88
Notice: Use of undefined constant _AM_TYPES - assumed '_AM_TYPES' in file /modules/system/admin/blocksadmin/blocksadmin.php line 99
Nicholas James
President - LaDads
http://www.ladads.info



242
Nick_James
Where are the constants set?

Two errors on this page.

Warning: constant() [function.constant]: Couldn't find constant _MD_AM_WELCOMETYPE in file /modules/system/admin/preferences/main.php line 81

Warning: constant() [function.constant]: Couldn't find constant _MD_AM_PROFILE_ALLOWED_GROUPS in file /modules/system/admin/preferences/main.php line 81

OOPS Version - XOOPS 2.3.0 RC
PHP Version - 5.2.5
MySQL Version - 4.0.27-max-log
Server API Version - cgi-fcgi
OS Version - Linux

safe_mode - Off
register_globals - Off
magic_quotes_gpc - On
allow_url_fopen - On
fsockopen - On
allow_call_time_pass_reference - Off
post_max_size - 8M
max_input_time - 60
output_buffering -
max_execution_time - 30
memory_limit - 64M
file_uploads - On
upload_max_filesize - 8M
Loaded PHP extensions «

* zip
* libxml
* xsl
* xmlwriter
* dom
* xmlreader
* xml
* wddx
* tokenizer
* session
* pcre
* SimpleXML
* SPL
* PDO
* soap
* SQLite
* standard
* Reflection
* pspell
* pdo_sqlite
* pdo_mysql
* mysqli
* mysql
* mhash
* mcrypt
* mbstring
* json
* iconv
* hash
* gettext
* gd
* ftp
* filter
* exif
* dba
* date
* curl
* ctype
* calendar
* bcmath
* zlib
* openssl
* cgi-fcgi
Nicholas James
President - LaDads
http://www.ladads.info



243
Nick_James
Re: Renaming and moving xoops_lib and xoops_data

Okay. For some reason the installed modules are not showing up.

Manual installed TAG and PROTECTOR by copying the code from an other install. Protector seems to be working.
Nicholas James
President - LaDads
http://www.ladads.info



244
Nick_James
Re: Renaming and moving xoops_lib and xoops_data

Well, my modem got fried by a power surge on Friday, so I switched to using an on-line connection.

And my dreamweaver refuses to make ftp connections to this account for some reason. It used to. So I am learning Filezilla.

Zilla will load the files into the directory you have selected... Ouch. So if you upload the modules to the wrong directory. They don't show.

Sigh. Okay. Lest see if we have it now.
Nicholas James
President - LaDads
http://www.ladads.info



245
Nick_James
Re: Renaming and moving xoops_lib and xoops_data

This upgrade is eating my lunch.

The original install went okay and the site is 'running' again.

But...

I am missing a concept somewhere. The installed modules are not showing up on the admin menu...
Nicholas James
President - LaDads
http://www.ladads.info



246
Nick_James
Re: Renaming and moving xoops_lib and xoops_data

Thanks
Nicholas James
President - LaDads
http://www.ladads.info



247
Nick_James
Re: Renaming and moving xoops_lib and xoops_data

Ah, well there it is. A very nice menu once I start the upgrade sequence. It asks me where those two files are.

I. C.

What is a good security practice for moving them out of the root?

If we want to move them later, after the upgrade, what file do we edit? Or can we just run the upgrade again.
Nicholas James
President - LaDads
http://www.ladads.info



248
Nick_James
Renaming and moving xoops_lib and xoops_data

Okay, it is probably already answered somewhere else, but does anyone have more information on this line?

"6. For security considerations, you are encouraged to move directories xoops_lib (for XOOPS libraries) and xoops_data (for XOOPS data) out of document root, or even change the folder names."

What else do we have to change so that XOOPS can find them if we rename and move them?
Nicholas James
President - LaDads
http://www.ladads.info



249
Nick_James
Re: problem check list

another cause of the 'white page' is that the PROTECTOR module has identified you as a hacker and locked you out of the site.

You may want to run the PROTECTOR recovery module and verify that you are not locked out.

You can also check the SQL database to find out if you are on the list.
Nicholas James
President - LaDads
http://www.ladads.info



250
Nick_James
Re: problem check list

Okay, here is the "Blank White Page" Help - see the quote below.

Somebody else provided the links were provided, but there are so many questions about it, lets just post the text here. Save folks from going to look it up.

The last time I upgraded {havent' tried 2.3 yet}, the blank white page was caused by the a script error. The script crashes before finishing leaving a blank white page.

The reason my script was crashing was because not ALL of the files uploaded.

So before trying to turn on the script debugging program, do a files check.

Upload the file checking files to root directory.
checksum.md5 and
checksum.php

Then run the php file to find the missing files
http:/www.your.web.address/checksum

Then upload the missing files.
That will probably fix most blank white pages.

If not, turn on the script debugging fix below. Last time I messed up so badly, I had to edit the database manually to turn it on. Then you can identify the line with the script error.


Quote:
Why do I have a blank white page on my site?

All so-called "blank pages" in XOOPS are caused by an error which terminates the script early. The goal of this page is to help you turn some debugging features on so you can get a more meaningful picture of what is going wrong, preferably some error messages. Please keep in mind, there is always an error which is causing the "blank page -- it may just be hard to get at.

You will not get a response in the forums if you just type "Help me, I get a blank page" because there is no way for anyone to tell what is wrong. If you can also give a list of the error messages you see, your chances for solving the problem are much better. (Also don't forget to specify which version of XOOPS you are running, whether it was an upgrade from a previous version, also your versions of mysql, apache/other webserver, PHP, and which theme and template set you are using. If you are using a lot of non-standard modules, it would be a good idea to list those too.)

A: To turn on debugging try the following things:
=
1. If you can get to admininstration menu, go to Preferences, select 'Main', and find the section on debugging options. Choose "PHP Debugging"

2. If you can't get to the administration page, but have access to mysql, try the query "UPDATE xoops_config SET conf_value=1 WHERE conf_name = 'debug_mode'". Be sure to make sure "xoops_config" matches the name of the config table in your installation. (NOTE: This does not work with XOOPS 2.2, see 2a)

2a. In XOOPS 2.2, go to your site's root file "recovery.php" and set the debug settings through the interface here

3. If you can't get to the administration page, and don't want to mess with mysql, but don't mind messing with PHP, then edit the file "include/common.php". Near line 83, change "error_reporting(0);" to "error_reporting(E_ALL);".

4. If this still doesn't work, your server or hoster may have turned off debugging in "/etc/php.ini" (linux) or "WIN_DIRECTORY/php.ini" (windows). Make sure there is a line in there "display_errors On".

5. If you don't have access to change this file (e.g. on shared hosting), then if the server uses the "apache" webserver, you can create a file called ".htaccess" to override the settings locally. This file should contain the line: "php_flag display_errors on". The tricky part is WHERE to put this file. Look at the URL you are having problems with. Put the file in the corresponding directory. e.g. If it is "someplace.com/xoops/" or "someplace.com/xoops/index.php" then you need to put the file in the main XOOPS directory. If it is something like "someplace.com/xoops/modules/system/admin.php" then put it in "modules/system" subdirectory of your XOOPS installation. etc.

B: Common Error Messages (and fixes)

Once you produce an error message you can begin to diagnose your particular problem. Generally you can ignore any 'Notice' or 'Warning' that you see. Be on the lookout for 'Fatal Error' as this is the most important one.

If you have been unable to produce an error message, proceed to section "C: Possible Fixes" and you can try some of the suggestions there.

Following is a list of error messages that you might see, along with steps you can take to remedy the problem. (Please feel free to add to this list, or correct the message so it more accurately reflects what PHP says.)

1. "Failed opening required..." or "Undefined function..."

This most likely indicates that a required file could not be loaded. First check if the file is there and in the correct location; if it is, then check the permissions of the file to make sure the webserver can READ it. It is also possible that the file is corrupted, or that your FTP program changed file/directory names. Check your FTP program settings (make sure you "preserve directory structure", and do NOT "force lowercase", etc...) and try again installing/uploading the files again.

2. "Call to a member of a non-object"

Very frequently this is caused by failure to connect to the database. If you get this error occurring near line 286 in kernel/configitem.php, then the database is to blame. Check your database settings in mainfile.php, and also make sure you have setup MySQL permissions correctly, and that the database is actually running. In particular, try and access the database directly - if possible using the same user/password that you specified in the XOOPS installation. Note that after you change permissions for users within mysql, you must perform "flush privileges" and/or restart your database server before the new settings will be applied.

This error can be caused by other problems as well. If you know PHP, check that file and line number and see which object is the culprit. e.g. If you see "$xoopsDB->query('blah');" on that line, then $xoopsDB is not an object, indicating the the database was not successfully connected. You may have to do a little digging to solve these problems.

3. "Cannot redeclare class ..."

The most frequent cause of this error is the installation of non-standard modules. Some modules are still in very early stages and have not been fully adapted to XOOPS 2 or have not been properly tested with XOOPS 2 and with other modules. Probably the module author has used "include" where she/he should have used "include_once". Usually the file identified in the error message will indicate which module is at fault. This module can then be deactivated.
* Or you can go to the line # specified and change the line from include('yourfile'); to include_once('yourfile'); - ackbarr

C. Possible Fixes (Compiled off of the XOOPS Forums)

Below is a list of various methods that have corrected the issue for different users on the XOOPS forums. Which one, if any, that will work for you is highly dependent on your particular installation. The list is not intended to be followed in order, but rather you should focus on what seems most relevant given your error message.

[1] In the php.ini, make sure that register_globals=on. You can check this by creating a test script with this single line of code:



NOTE: The XOOPS core should work without changing this to ON, but some modules may not and thus will give blank pages. Turning on the debugging options outlined earlier in this page will help you track down which section or module is causing the error.

[2] Sometimes the PHP GZIP module is not added or correctly compiled with PHP, go into the XOOPS admin (system>preferences) and turn off support for GZIP.

[3] Make sure that you have installed XOOPS according to the installation directions by CHMODing the cache dirs on a UNIX server.

[4] Re-upload the theme files for whichever theme you're using. Sometimes things get corrupted via FTP upload. First upload phpkaox and set your system preferences to use this theme.

[5] Make sure that your running PHP 4.12 or later (preferably 4.22 due to security fixes in PHP)

[6] Make sure that you dont have another CMS interferring with XOOPS like PHPNuke, PostNuke, etc.

[7] Make sure that the cache, uploads, templates_c directories are CHMOD 777 (anonymous r/w permission on Windows)

[8] Try turning Safe Mode off on the server. (Not recommended as it is less secure).

[9] Double-check the following permissions:

755 - all directories which dont require writing from the web server
777 - all directories which do require writing from the web server
644 - all files which dont require writing from the web server
666 - all files which do require writing from the web server
444 - mainfile.php

[10] Try switching to the default theme. Several themes are meant for XOOPS 1 or have not been properly converted to XOOPS 2, causing a variety of problems. If this fixes your problem, at least you've identified the source of the problem. If you find a problem with a theme, please post on xoops.org forums and/or notify the author of the theme.

[11] Try disabling all non-standard (i.e. anything not included with XOOPS download) modules. If you cannot get to your admin menu, you can do this by editing the xoops_modules table via MySQL or phpmyadmin. Several modules are in early stages and have not been properly tested with XOOPS 2, sometimes causing problems. If this fixes your problem, try re-enabling one at a time, to determine exactly which module(s) are causing problems. If you find a problem with a module, please post on xoops.org forums and/or notify the author of the module

[12] Added by carnuke ... if http://mysite.com/user.php returns a blank page, see this FAQ here

[13] Check if MySQL extension is loaded in php.ini:
extension=mysql.so

--- Additional details submitted by Max-Realms on 2005/3/26 1:06:34

In my case, I got blank pages without debug errors showing. After a while of troubleshooting, I found that my database "user" had exceeded max_questions (50,000 per hour).

My server is hosted, so I can't change anything there. However, I found that if I created several more database users and gave them each full access to the XOOPS database, this problem was fixed. I don't know anything about Mysql, but perhaps when a db has multiple users, they share the load.

If this is in fact true, then it would be great if the mainfile.php and/or core files could be setup to skip to the next available database user when the default one exceeds these limts.

David Goodman
http://www.max-realms.com
Nicholas James
President - LaDads
http://www.ladads.info




TopTop
« 1 ... 22 23 24 (25) 26 27 28 ... 33 »



Login

Who's Online

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


Members: 0


Guests: 158


more...

Donat-O-Meter

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

Latest GitHub Commits