21
Tobias
Re: Another article 1.0 question
  • 2007/7/8 22:18

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


As for the technical problem: I've reproduced it on my sandbox install, and I see what you're talking about. I think it may have to do with the variable not being flushed before the new value gets written to it. That's a wicked and probably wrong way of putting it, but the symptoms:

1. No value in database + new value being put in through the form --> value gets written to the database correctly. Doesn't matter whether it's a new submission or an old submission without the respective value in db.
2. Value in database + no new selection being made in the form --> nothing written to db, and old value stands correctly.
3. Value in database + selection being made in the form --> writes the word "Array" to the db.

I have a few ideas what to do about that, and I'll probably get a chance to look into it over the next days. Not promising anything, though.

As for them friggin real estate sharks: I think you might get much more traffic through your site if you drop the word "Buenos Aires" in a prominent position. As far as I can see, it's not really mentioned anywhere --> Google won't send you the people who want to know about that sort of abuse in that place. Perhaps, you can do some semantic search engine optimization with your front page.



22
Tobias
Re: Another article 1.0 question
  • 2007/7/8 17:41

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


It doesn't really surprise me that it's getting lost if it's not written to the database. I've tried to understand the exchange you've had with phppp in the other thread, and I might be misunderstanding something. But if it's not written to a database, and not stored in a cookie (bad idea for your purposes), then it's going to be lost.

Now it seems that that's not the problem here as you can see the status of the item in the article display. Just the form doesn't retrieve the status while it's being built. And that's where you might have to step in and make a database query. But I would be lying did I say I understood what that art_source variable is and where it comes from.

I don't think it's only important to you people. On a larger scale, it matters that there're folks watching out for the common good, and not leaving it all to those who only seek to maximize their profit. Now, in Argentina, you might be currently supported by broadly shared sentiment. Even so, the people of Buenos Aires will have to thank you one day.



23
Tobias
Re: article 1.0 email to a friend feature doesnt work?
  • 2007/7/8 17:30

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


Like what error? Because it works for me. You also don't have to write an email address in there as that one's added from your general XOOPS email settings anyway. Just try with something like "Usuario en Descontrol.org" or something. You need the quotes around the string.



24
Tobias
Re: article 1.0 email to a friend feature doesnt work?
  • 2007/7/8 17:06

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


OK, I get the same Didn't ever realize.

That comes from /Frameworks/transfer/plugins/email/action.email.php around line 47, where it says:
}else{
    require_once 
XOOPS_ROOT_PATH."/Frameworks/art/functions.php";
    
$xoopsMailer->setFromName(mod_getIP(true));                
}


Change the line with the mod_getIP to something like
$xoopsMailer->setFromName("info@yoursite.org");

and it should work!



25
Tobias
Re: Another article 1.0 question
  • 2007/7/8 16:47

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


Hm, that sounds more like you have to hack the database and to have a field which can only have the three intended values. In any case, if the script returns the word "array," then there's apparently a problem with reading out the correct data from the database. Sounds more like a little php hacking than like dropping a javascript into a template. Something like that.

In any case, that's a little beyond my scope I'm afraid.

That's a very good and important site, by the way. Buenos Aires?



26
Tobias
Re: Which chmod attributes for a photo gallery album?
  • 2007/7/8 16:15

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


The php script overwrites the permissions you set through the shell on the parent directory? That is outrageous! Then you might really have to make sure that the apache user isn't owner and doesn't belong to the group.

Just so we're on the same page: The aim is that the parent directory is set to 555, and the individual user directories to 755 so that users can write into them and delete from them, but cannot delete de user directories themselves.

Sorry, I'm at the end of my wits!



27
Tobias
Re: article 1.0 email to a friend feature doesnt work?
  • 2007/7/8 15:55

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


If you fill in all the settings, it should populate the sender address with what you want to be written there. If it doesn't, then there's probably one more setting we're overlooking here.

Other than that: The IP is going to come with the message headers. You can't prevent that, only spoof, but then you're a spammer. But it shouldn't show in the "sender" field if it's set up correctly.



28
Tobias
Re: Which chmod attributes for a photo gallery album?
  • 2007/7/8 15:15

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


You mean you own the server? Try to take ownership for root.

chown root:root blahblahblah
and then
chmod 777 blahblahblah

You probably have to be root to do that, or sudo if you can. Blahblahblah are the directories. I'm not sure this isn't dangerous. You might find a better user then just root. Just for testing purposes.

But perhaps, I've also been talking a bunch of nonsense and you can prevent the directories from being removed by just taking write permission away from their parent directory. You could try setting the parent directory to 555. But that may recurse into the child directories, so that your users won't be able to upload anymore.

This question sounds really basic, but I'm terribly unsure. I'm just a single user without public access to my machine. You may want to wait for someone more knowledgable to give you the real webmaster tips.

*Edit: Yeah, this looks like it might be worth a shot. Consolidate all the directories you want to have, then chmod the parent directory to 555. I can quickly get that scenario to work on my box. So I can write to the child directory, but not remove the child directory itself. Not sure whether there could be complications with the web server, though.*



29
Tobias
Re: Which chmod attributes for a photo gallery album?
  • 2007/7/8 14:52

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


Okay, in that case, you'd have to manage ownership so that the "user running the webserver" cannot remove the directories. So you could chmod them to 777, but the directories themselves still couldn't be removed by anyone other than the owner. Or root, of course. If I'm not mistaken, that is.

If you have a relatively static set of directories, perhaps you can get your webhost to change ownership of those directories for you. That might mean that you yourself wouldn't be able to remove these directories either.



30
Tobias
Re: Which chmod attributes for a photo gallery album?
  • 2007/7/8 13:51

  • Tobias

  • Not too shy to talk

  • Posts: 172

  • Since: 2005/9/13


*Edit: Ooops sorry, I've misread. In any case, I hope you're not talking about giving everyone ftp access! If you do, they should not be able to delete/change permissions on directories for which they're not the owner, should they? Original post follows:*

Depends a little on your servers setup, but if they can up, then they can also delete. From the point of view of file permissions.

Now, if they can upload only through some php script, such as a XOOPS gallery, then it's probably the user who runs the webserver who has the appropriate permissions and ownership, not the world or the person who's looking at the gallery through a browser. Meaning that your visitors can only delete if the php script provides that option to them. They hopefully don't have ftp access anyway.

In any case: It's not about chmod, but about tuning the permissions for your gallery, which, I assume, integrates with xoops. If you're talking about ftp, then it's a different story.




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



Login

Who's Online

252 user(s) are online (136 user(s) are browsing Support Forums)


Members: 0


Guests: 252


more...

Donat-O-Meter

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

Latest GitHub Commits