31
tripmon
Re: how can i delete notifications from old users automatically?
  • 2006/11/17 9:14

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


I'm guessing you mean the PM's that the notifications cause to clutter the dB? If so try MP Manager HERE

Or perhaps you actually want to remove the notifications... if so the best thing would be to disable them in the admin section of the module(s) causing issues (news). Trying to remove them for 20k users from the dB seems just silly when you can just turn notifications off per module... If you want to, you could try limiting the notification options and see if that helps as well.



32
tripmon
Re: mxdirectory 3.01 RC1 blank page
  • 2006/11/15 19:22

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


Sorry, Have been to busy to finish testing the new changes.

Hope to have it out soon.



33
tripmon
Re: Uploaded files but can't get to the welcome page
  • 2006/11/14 16:49

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


try
http://xoopytester.co.uk/install/



34
tripmon
Re: Verify manifile.php....How ?
  • 2006/11/7 20:13

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


Hi Dave,

Yes, fwrite should fail under the assumption that IIS has only 'read' permissions. Of course mainfile would never be set to 'Read-Only' until after install was complete.

re: is_writeable alternative, sadly...

microsoft c runtime library only reports the read-only flag from its stat() implementation; if the file is not marked as read-only in the regular file attributes (eg: what you see using attrib or dir commands), then PHP (and any other ANSI C program) will see it as writable.

Many Windows hosts will allow you to set actual file permissions via their control panels, but this is almost always implemented per directory not per file.

Actual message in admin section reads:Quote:
WARNING: File /inetpub/account/xoopsfolder/mainfile.php is writeable by the server.
Please change the permission of this file for security reasons.
in Unix (444), in Win32 (read-only)

Which is about as good as it gets I guess.

Of course that's Just my opinion, and I could be wrong... would love to hear more input on this as it confused me significantly when I first ran up on it.



35
tripmon
Re: Verify manifile.php....How ?
  • 2006/11/7 19:04

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


If you set all of the accounts (common user, administrator, and server) to 'read', then ALL IS WELL...

While the file is actually writeable by the operating system (EXAMPLE: an administrator who is logged on to the windows server) it is not writeable by the **web server** process and you can ignore the error message.

To make the error go away: Quote:
This can be done by opening windows explorer (from the server), finding mainfile.php, right clicking, choosing properties, and setting the attributes to READ ONLY.


Very confusing isn't it

If you are doing work for a customer and do not want the message to appear & do not have the ability to set the file permission to READ ONLY, you can edit the admin.php file to remove the error message.



36
tripmon
Re: Verify manifile.php....How ?
  • 2006/11/7 17:07

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


NTFS stands for NT File System. Which is what most windows servers configured for production environments use as their file system.

With windows, you need to set the file as read only through the operating system (as opposed to setting the permissions of the web server accounts) in order to get the message to go away.

This can be done by opening windows explorer (from the server), finding mainfile.php, right clicking, choosing properties, and setting the attributes to READ ONLY.

Notice that this does not have anything to do with the web server (IIS) or the accounts that the web server is running, but is done at an operating system (windows) level.

It is very confusing because you can also protect the file by IIS Account permissions which is what you were talking about re: single reading" for the common user and "total control" for the administrator and server...

If you set all of the accounts above (common user, administrator, and server) to 'read'... it does the same thing as far as restricting access (well almost), but the message in your administration section will remain. The reason is that the script checks to see if the file is writeable by the operating system.

Hope that helps



37
tripmon
Re: I really have a problem!
  • 2006/11/6 17:03

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


Can you post some examples of the actual code you are trying to use as well as environment vars (server type, php ver, XOOPS ver, etc.) info



38
tripmon
Re: mxdirectory 3.01 RC1 blank page
  • 2006/11/6 16:55

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


Got bumped back a bit due to reality constraints... Am testing the new changes now & hope to have a new version out Fri. or Mon (Nov. 13).

more soon



39
tripmon
Re: Verify manifile.php....How ?
  • 2006/11/6 8:59

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


you can not set this file to 444 because you are running on a Windows server... just make sure that IIS and Everyone does not have write permission.

Filezilla WILL NOT allow you to set permissions on a Windows Machine.

Most windows hosts will not let you make the changes necessary to get the message to go away from a control panel.. you can ask them to set the file to read only via NTFS permissions and see if they will.

If you really want to remove the message, you will need to:
1) contact your host to set NTFS permissions to read only
2) verify that no accounts have write permissions & manually edit the admin page and remove the warning.



40
tripmon
Re: Module Rename
  • 2006/11/2 21:23

  • tripmon

  • Module Developer

  • Posts: 462

  • Since: 2004/2/28


BTW, modules can be built to support renaming... this will usually be mentioned in the module's readme, but you can check by looking in the top few lines of xoops_version.php for something like this:
(the important part regarding renaming is the first line, second part makes sure you have not renamed the directory with bad characters and may not be there.)
$mydirname basenamedirname__FILE__ ) ) ;
if( ! 
preg_match'/^(D+)(d*)$/' $mydirname ) ) echo ( "invalid dirname: " htmlspecialchars$mydirname ) ) ;


the actual variable name (in above example $mydirname) may not be the same.

IF you see this code, that means you can rename the module simply by changing the folder name before installing the module.

HTH




TopTop
« 1 2 3 (4) 5 6 7 ... 44 »



Login

Who's Online

162 user(s) are online (110 user(s) are browsing Support Forums)


Members: 0


Guests: 162


more...

Donat-O-Meter

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

Latest GitHub Commits