I believe the way you have to do this now (because of a change the the way headers are sent) is by wrapping it in an iframe. So the content of your custom block would look something like:

Very strange.

You might try downloading the .zip file again from a different server than the one you previously used. It might be that one of the servers has a corrupt copy of the zip file.

Duplicate post - you can see what's been tried so far here

This error message indicates there is a problem openning the /xoops/kernel/object.php file. You may want to make sure that the file is actually there and looks like there's "something" in it... (e.g. it's not a zero length file - which can happen sometimes on a failed ftp upload).

It would help to know which version of XOOPS & PHP you're using too...

You might want to follow this thread.

You can also try here on the dev.xoops.org site.

And here on the xoops-tip.com site.

Please submit a bug report here. It would help if you would include the following in your bug report:
* XOOPS and PHP versions
* Turn on PHP debug in XOOPS Admin and report any messages that are displayed when you submit the listing.
* The message that appears after the user submits the listing.
* Your settings for maximum file size, maximum height and maximum width.
* The type of file (jpg, gif, png) that failed (attach the file that failed to upload to the bug report if you can)
* Anything else you think would help isolate the problem.

Here are a few things to check:
* Make sure you chmod the /images/shots directory to 777.
* Logo types allowed are .jpg, .gif, and .png.
* Verify the image doesn't exceed the "Logo Max File Size", "Logo Max File Width", and "Logo Max File Height" settings. These are set in Admin > Preferences > Yellow Pages > Module Preferences.
* Verify the image is smaller than the "upload_max_filesize" setting in php.ini.

I'm not aware of any document that tells you what needs to be done to convert a module that was designed for an older version of XOOPS to a more recent version.

The best thing to do is to try it on a test site. In my experience there are some minor tweaks that need to be done to update most older modules, of course that depends on the module. Some of the older modules I've found need to be updated with some of the more recent security changes, include header and mainfile in the right place, etc.

It might help to name the module you're looking at in this thread so you can find out if someone else is already using it on a more recent version of Xoops. You might luck out and find that it "works" or will work with minor mods that someone else has already completed.

I had a similar problem - earlier today as a matter of fact. I've checked around and apparently several hosting companies have decided to not allow php.ini override values in .htaccess files any more.

I had changed upload_max_filesize to allow larger uploads and my hosting company turned off the ability to override the default value. This causes php_value statements in .htaccess files to be invalid and so it throws a 500 error.

To verify this is the problem go to your cpanel (or 'other' control panel) and check your error log. You'll see a message that says something to the effect that php_value is not allowed.

If this is the problem then all you have to do to get your site back is remove the php_value settings from your .htaccess file. Unfortunately, this also means that you can't override the default php.ini settings chosen by your hosting company any more.

* EDIT * - After my initial post I did find that, in my case, this was due to the hosting company as CGI (PHPsuexec) instead of as an Apache module. It is possible in this scenario to change "most" of the php settings by removing the php_value settings in the .htaccess file as described above and then including a php.ini in your root directory with the appropriate php setting in the php.ini (upload_max_filesize = 5M in my case).

Another potential issue when switching to PHPsuexec is that you can no longer have directories set to 777. The max. allowed is 755. If you have directories set to 777 they will also cause a 500 error. You can find a more detailed explaination from one of the hosting companieshere.