Quote:
My Profit ?
Teach me any profit generated by that Agenda-X users is transferred to piCal.
Though I proud that piCal is far more excellent than Agenda-X as Calendar or Event Manager Module,
I never recommend piCal to such a person who thinks that Agenda-X is better.
To begin with, comparing them is meaningless.

Quote:
Did you read whole of his article?
He wrote REMOVE it as same as my article.
-------------------------
Above-mentioned modified information is not information from the module manufacturer but temporary.
Therefore, when it is not possible to correct it in the self-responsibility, we will recommend the module to be made the temporary each folder save from the module manufacturer to open to the public of a formal correspondence version in the safe place (Inaccessible place according to WEB a browser etc.).
-------------------------

Quote:
No!
2.0 beta 2 has the same sacurity hole.
Have you read the source codes ?

And the security hole of 1.2.2 or 2.0 beta 2 is found by me, not by onokazu.

I read the source and I had the conviction wjue does not have skills to be able to create modules which can be opened to the public.

The hole can be scared by only changing register_globals OFF, but I can't believe his skills any more.

Though the hole is caused by a third party module, the hole deteriorates the reputation of whole XOOPS.
In fact, the "slash dot news" wrotes the articles which the security hole of Agenda-X is misunderstood that XOOPS's security hole.
Only writing that do not use the module which has security holes and lowers the reputation of whole XOOPS might be a "PROFIT" for all.

onokazu also wrotes to the all of XOOPSers :
When you adopt a module made by the third party, you should ascertain the module enough.

Quote:
Deactivating module has non-sense.
Crackers can attack the defective files directly.
You have to REMOVE all of Agenda-X files from your site.

In Japan, a XOOPS site in sourceforge has been cracked by weakness of Agenda-X.
This was also taken up in the "slash dot news".

wjue knows Agenda-X 1.2.1 has a security hole, and he released 1.2.2.
But I've just found the fixes are no use.
Thus there is still a serious security hole in XOOPS sites using Agenda-X 1.2.2 or 2.0.0 beta2.

Deacivate and remove all of Agenda-X files from your XOOPS site now.
Only deactivating module has non-sense, because the security hole caused by files.

REMOVE THEM RIGHT NOW.


This is a summary of XOOPS Japan's news posted by onokazu
----------------------------------------------------
From XOOPS Japan Team

The weakness to be able to execute an arbitrary external file by "Agenda-X" module was discovered.

This bug : to the distribution package of the main body of XOOPS and XOOPS because it is not included module weak. It is not necessary to correspond especially on the site not included in following "Site where the action is necessary".

There are roughly separately two reasons taken up as a news story this time.

The first reason was to have done the cracking attack which pierced the weakness of this module on a domestic major site.

The second reason is of my wanting XOOPS users to understand the adoption of the module made by the third party should be ascertained enough.

It is important that there is no weakness of the module included in the main body of XOOPS and the distribution package.
----------------------------------------------------
(sorry for bad auto-translator)

It's easy to change.
Only edit myalbum_viewcat_table.html of your template set.


edit here (line 64)

The feature of resizing main photo only works under ImageMagick, NetPBM, or forced GD2.
Perhaps you don't have GD2 environment.
Thus I can't help you about resizing and the quality of thumnails.

The problem of uploading size will be solved only if class/uploader.php is replaced the file of XOOPS original core.

I can't support for hacked environment at all.
(myDownloads RC1 is one of "hack module" like IPBM, 4images ...)

hi m0nty.

There is a typo in class/uploader.php.
This means that the limitation for height is used by the limitation for width.

Or, do you use myDownloads RC1 too?
Since this module overwrite class/uploader.php, I can't guess the behaviour.

I know you can't use ImageMagick or NetPBM.
But did you try "force GD2" ?
If it succeed, you can get the images auto-resized.

Quote:
Perhaps, original Image Manager cant do that.
Use myAlbum-P's Image Manager Integration.

And the module name is not "My Album" but "myAlbum-P".
Nobody call "WF-sections" as "sections".

Of course, myAlbum-P supports PNG.
Only I don't know MIME type of image/png.
(Normally, the MIME type of PNG is image/x-png)

All you have to do is add "image/png" into the end of include/read_configs.php like this:



I know it is a weakness of myAlbum-P that MIME type is not editable from control pannel.
It should be improved.

hi m0nty.

Although it's not a bug, my wrong designing cause the trouble in fact.

This is a disclaimer appended to myAlbum-P's download.
---------------------------
Two templates - myalbum_photo.html & myalbum_photo_in_list.html - has been modified radically.

If you use myalbum or myAlbum-P older than 2.60 with customized templates , you should remake templates after updating this module.

A case in www.xoopscube.jp:

When an admin using Norton Internet Security installed myAblum-P, he got DB errors with INSERT.

After he had uninstalled and re-installed it, his myAlbum-P has been running rightly.

Though I don't know tom uses Norton or not,
Uninstall & reinstall the module is an efficient measure when you get DB error.