Menu
▾
▴
phpwebsite-developers
|
From: Matthew M. <ma...@tu...> - 2002-12-08 17:50:04
|
Greetings all, The core_settings table has been removed from CVS. The text and date information is now handled by files, which you should receive when you update. Note that the profanity filter is now a strict search and replace. Take a look at the file in the conf directory to see how it works. I have tested installation and the parse function and both appear to work. Those of you who need to use the parse function DO NOT call it with PHPWS_Core:: as it needs object information to function. I tried to program it otherwise but branches complicate the matter too much. Jeremy: Check your security module. I have commented functions that you can remove as they are no longer needed. Adam: I tested pagemaster with parse and it worked well. You will need to add the function on the line that imports the POST into the section object. Also, I have put a switch in the setup.php file for those who want to install with a version under 4.2.2. It was suggested we use a yes/no form but I prefer this way. The admin would have to physically alter the file instead of clicking a button. Later Matt -- Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
|
From: <ad...@tu...> - 2002-12-08 19:34:38
|
> The core_settings table has been removed from CVS. The text and date > information is now handled by files, which you should receive when you > update. Woot! > Adam: I tested pagemaster with parse and it worked well. You will need > to add the function on the line that imports the POST into the section > object. I will get that in asap. I'd like to bring something up along these lines. I'm wondering if parse() should handle the profanity filtering or breaker(). IMHO, I think we should store the profanity in the database and filter it on display. That way, if an admin decides to change his/her filter, any previous profanity will be revealed. Thoughts? > Also, I have put a switch in the setup.php file for those who want to > install with a version under 4.2.2. It was suggested we use a yes/no > form but I prefer this way. The admin would have to physically alter the > file instead of clicking a button. +1 here Lates, Adam --------------------------------------------------------------------- Adam Morton Developer - Electronic Student Services http://phpwebsite.appstate.edu Founder - Appalachian Linux Users Group http://alug.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2002-12-09 12:16:28
|
> I'd like to bring something up along these lines. I'm wondering if > parse() should handle the profanity filtering or breaker(). IMHO, I > think we should store the profanity in the database and filter it on > display. That way, if an admin decides to change his/her filter, any > previous profanity will be revealed. Thoughts? Good point. I think we could leave it up to the developer. You don't have to call parse before you save the data. You could just call strip_tags and addslashes on your own, then call profanityFilter during display. BTW Adam, wasn't there something breaker was not working with properly? Thanks, Matt |
|
From: <ad...@tu...> - 2002-12-09 14:55:49
|
> Good point. I think we could leave it up to the developer. You don't > have to call parse before you save the data. You could just call > strip_tags and addslashes on your own, then call profanityFilter during > display. This kind of comes back to something I was discussing with you earlier, Matt. You remember when we were talking about a function that parses user input and a function that parses output. We pretty much have those now in parse() and breaker() but I'm wondering if we should make these functions standard [parseInput(), parseOutput()]. Just a thought... > BTW Adam, wasn't there something breaker was not working with properly? Yes check out the bug on sourceforge: 645750 Adam --------------------------------------------------------------------- Adam Morton Developer - Electronic Student Services http://phpwebsite.appstate.edu Founder - Appalachian Linux Users Group http://alug.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2002-12-09 16:16:59
|
> This kind of comes back to something I was discussing with you earlier, > Matt. You remember when we were talking about a function that parses > user input and a function that parses output. We pretty much have those > now in parse() and breaker() but I'm wondering if we should make these > functions standard [parseInput(), parseOutput()]. Just a thought... Adam, Steven, and I talked about the above issue. Here is what we decided. sqlInsert and sqlUpdate will take charge of the addslashes issue. They will automatically test text before it is saved. The developer will never worry about the save format. parse will split into parseInput and parseOutput. Input will strip tags. Output will put breaks on newlines and strip profanity. Expect these changes later today, Matt Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2002-12-09 17:08:41
|
> sqlInsert and sqlUpdate will take charge of the addslashes issue. They > will automatically test text before it is saved. The developer will > never worry about the save format. Ok, this has been committed. As a refresher: You don't need to addslashes to anything before sending it to sqlInsert and/or sqlUpdate now. They will take care of it. You do not need to serialize arrays or (ick, not) objects before sending them to sqlInsert and/or sqlUpdate. You DO have to unserialize after a sqlSelect. I could have this done automatically but it would exponentially increase its process time. The 'parse' function should not be used any more. Use parseInput to remove unwanted tags and parseOutput to remove profanity and to break the text. You might want to grep your modules for parse and addslashes to clean it up. Please respond if you have any problems. Matt -- Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2002-12-09 17:53:13
|
More information: I have removed addslashes and serialization from many of the core files. I have ALSO removed the function serialize and unserialize from the Text class. If you are using them (I don't think anybody did except for me), dump them. Matt -- Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X