SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 54
  1. #26
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    still the rating system is not rating the items which have encoding charaters the only step i am missing now is to replace the utf8- string function for the normal ones. which is step four from boen suggestions.

    I hope it can be fixed these issue

    the string functions below are the one used by the rating system most of the time. what would be the substitution ones in utf-8 string functions for the normal ones below?

    PHP Code:
     if ($varItem != null && strlen(trim($varItem))  != 0)
            {
              
    // Check if Magic QUotes is ON
              
    if (!get_magic_quotes_gpc())
              {
                
    $varItem addslashes($varItem);
              } 
    I had to put back the other type of encoding

    HTML Code:
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    If I put utf-8 then the rating won't refresh a similar problem I had before but caused by a / at the end of the rating php file, this time comes back again if I don't put the meta tags with ISO-8859-1 encoding. The database still in utf-8 there is obvious a mixture here between the encoding of the webpages and the database encoding but I can't change the header encoding because it will throw out the rating system and won't display the encoding character in the browser from the database. a very complicated case help please

  2. #27
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you're experiencing the second problem Florent V. talked about... a problem which I hoped isn't true in your case, but it is... without knowing, you've already populated your DB with ISO-8859-1 data, converted to latin1, and your DB has written them in UTF-8. Doing a convertion now would be really hard.

    Let me explain in a little more detail (hopefully that would help you find a convertion path of some sort... and hopefully, it would help me understand encodings better) - up until now, you accept form input in ISO-8859-1, PHP gives the MySQL extesion this ISO-8859-1 text, and the MySQL extension encodes it to latin1 (the default MySQL encoding), after which it sends it to MySQL. MySQL decodes the text as latin1, but writes in the received characters as UTF-8. During this translations, a lot of the characters could be misread, but whatever happens, the numbers are still the same.

    Now that you changed your HTTP header to UTF-8, when the DB gives PHP the data as UTF-8, PHP displays them as UTF-8. But it received them as ISO-8859-1, which uses different numbers for those special characters.

    The best way is to of course wipe your data, but since that's probably not a viable solution, the alternative is to dump all of your SQL data (in the form of "INSERT" queries) in an ANSI encoded text file, convert the text file to UTF-8 (after you make sure that the data in it is correct), then reexecute this file with UTF-8 as the client encoding.

    If a plain dump like this doesn't work, I can only think of one more really painful thing to do... a thing which I haven't done, and never will (since I leared about UTF-8 early)... manually generate such an SQL dump script with PHP (and make sure to explicitly specify the encoding as ISO-8859-1 with stream_encoding()), and then view the content with Notepad. If it's fine, convert the file to UTF-8 using Notepad, then execute this file against the DB to replace your old data with this new, now truly UTF-8 encoded data.
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  3. #28
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you're experiencing the second problem Florent V. talked about... a problem which I hoped isn't true in your case, but it is... without knowing, you've already populated your DB with ISO-8859-1 data, converted to latin1, and your DB has written them in UTF-8. Doing a convertion now would be really hard.
    Don't worry about the database population from the rating system I am building the site still and none of the data in the database right now is official. so in case I have to erase them it will be ok thank God I didn't learn this encoding issues later.

    Now, what I have thought to be the real issue causing the rating not to be able to insert user data entry to the database (item name= "pesé"). The item name is one of the fields of the rating table which this field comes from the meta tags encoded as "charset=ISO-8859-1" into the database utf-8 as you have explained in your previous post, And that where I understand the problem lays down. is there a way where we can place a functions where it converts the data from charset=ISO-8859-1 to database utf-8. Another case as you said is that I can wipe out the database and change it's charset to be equal to ISO-8859-1 and it is ok right now since I don't have a large database I can easily re-do it again. I was wondering why putting charset=utf-8 at the header of the website does not work? so it can be compatible with the database charset?. I have given some thought and one thing I thought that changing the header to utf-8 didn't work was because the collations in the rating table fields in the database could be causing part of the problem. is that possible that the coalition configuration could cause trouble at the moment of inserting a field in different charset or something like that. The collation of the table rating in the database is "latin1_swedish_ci" where it should be latin1_spanish_ci because that one language used in the web site. So another understanding of the cause of the problem is laying down at the INSERT point where the user rating data as I said before is entered in the database from charset=ISO-8859-1 (website header) to the database in utf-8.

    The rating INSERT is as below.

    PHP Code:
     if (Rating::CheckRatingsByIp($varItem) == 0)
              {
                
    $ipAddress $_SERVER['REMOTE_ADDR'];
                
                
    Database::ExecuteQuery("INSERT INTO `rating` (`item_name`, `rating`, `ip_address`, `date_rated`) VALUES ('{$varItem}', {$varRating}, '{$ipAddress}', NOW())""InsertRating");
                
    Database::FetchResults("InsertRating");
                
    Database::FreeResults("InsertRating");
                
    Database::RemoveSavedResults("InsertRating");
                
                
    // Information for the Output
                
    $averageStars  Rating::CalculateAverageRating($varItem);
                
    $newClassNames "rated " Rating::ShowStars($averageStars);
              }
            } 

    Now that you changed your HTTP header to UTF-8, when the DB gives PHP the data as UTF-8, PHP displays them as UTF-8. But it received them as ISO-8859-1, which uses different numbers for those special characters.
    How could I recieved and display the database as utf-8 once. Becuase when I change the header to UTF-8 then it won't display the character I mention before in previous posts and it won't rate either those items with special character encoding.

    The best way is to of course wipe your data, but since that's probably not a viable solution, the alternative is to dump all of your SQL data (in the form of "INSERT" queries) in an ANSI encoded text file, convert the text file to UTF-8 (after you make sure that the data in it is correct), then reexecute this file with UTF-8 as the client encoding.
    Can you please outline the steps to make a database dump in a INSERT form? save it in a text editor in a utf-8 format etc... please outline all the steps

    The stream_encoding()) would be really a great pain I don't have a complete a idea of what it means but I can imagine what it is. It would be doing manually all the work mysql and php would do automatically if both would have the same charset=utf-8 or ISO-8859-1.

    Since I don't have a large database yet i prefere to re-write the database and makes things a little eraser in the future, I think I am up changing both charset the php and database one to be the same and avoid future complications.

  4. #29
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the data in the database is in the wrong encoding, you can easily convert it with a query or two. You can also write a script (in Python, PHP) to just select all the data and re-update the fields with the data in the right encoding.

  5. #30
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The conversion need to be done at each query of the web site, well you said with two queries how is that done?


    How would be that script (in Python, PHP) to select all the data and re-update the fields with the data in the right encoding?

    Please...

    Right now again the the special character mention in previous posts still are not displaying. Right now I have set up the meta tags
    PHP Code:
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
    And it displays pezuas instead of pezuñas plus it won't insert the user rating data into the DB table "ratins"


    Help....

  6. #31
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, if wiping the data is feasable, forget about everything else, and do wipe it, as it will be much easier that way. Make everything in UTF-8, as already discussed, and then repopulate your DB with the now correct UTF-8 input from UTF-8 served forms. Do not change anything to ISO-8859-1 - just wipe your DB data, and repopulate it with your new script.

    BTW, I've always said UTF-8 is the most healthy encoding around... people rarely believe (and/or understand) me before getting their first headache ;-)
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  7. #32
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wiping all the data includes deleting the database and do it over again or deleting just the tables..

    Tell me the steps I need to follow on re-building a new database so it can be compatible on utf-8 can you please outline the database building steps.

  8. #33
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think they call the operation "purge". That is, delete all of the content in the database i.e. the content in each table (with no exceptions), but leave the tables themselves intact. As you said, they are already using UTF-8 encoding, so this means they're OK. Their content is the problem, and that is why you need to remove it, and repopulate it. You could also delete and recreate the tables themselves, but you don't need to go that far.
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  9. #34
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's basically deleting all the table information or content. If that doesn't work then I will have to delete the whole database. How do I know for sure the tables are in utf-8 LOL don't want re-populate the data again with the tales in another encoding other than utf-8

  10. #35
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We talked about that already - make sure everywhere there's "collation", "charset" or "encoding", you see "UTF-8", "utf-8", "utf8" or "utf8_general_ci" (whatever option from these is available). Check the DB's default collation, each table's collation, each (VAR)CHAR/TEXT column's collation. Feel free to look around for other places where similar other options may exist (though as far as MySQL is concerned, I don't know of any other such places).
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  11. #36
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In the collation config. There are utf8-portuguese_ci and many other languages but utf-8along doesn't exist. Should I specify the language that the information is written or simply pu utf-8_general_ci ?

  12. #37
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Use "utf8_general_ci". Honestly said, I'm not sure of the difference between those UTF-8 variations, but if "utf8_general_ci" is good enough for information_schema, it's good enough for any DB, and therefore, the one that should be used.
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  13. #38
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cool I will try using utf-8_general_ci for the DB, table,char,TEXT, collotion config.

  14. #39
    SitePoint Member
    Join Date
    Mar 2005
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think your problem comes from database.
    To fix this you have 2 ways:

    1. Change database to use ut8 character set and after that change each table:
    ALTER TABLE <table> CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
    This way you'll keep the wrong words you already have in those tables, but the next ones you enter....you'll see them correctly.

    2.If you want to fix the already stored records then you should use this second method.
    - create new databse useing utf8 charatcer set:
    CREATE DATABASE <new_database> CHARACTER SET utf8;

    -dump the existing database to a file using utf8 encoding:
    mysqldump <database> -u root -p --default-character-set=utf8 > database_bkp.sql

    -replace old encoding with utf8
    I presume, your old database encoding is "latin" so that, you need to replace in database_bkp.sql this way:
    sed -i 's/CHARSET=latin1/CHARSET=utf8 COLLATE=utf8_general_ci/' ./database_bkp.sql

    -now populate the new database with modified sql dump file:
    mysql <new_database> -u root -p < ./database_bkp.sql


    Hope this helps.

  15. #40
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    -replace old encoding with utf8
    I presume, your old database encoding is "latin" so that, you need to replace in database_bkp.sql this way:
    sed -i 's/CHARSET=latin1/CHARSET=utf8 COLLATE=utf8_general_ci/' ./database_bkp.sql
    you said you presume, Now how can I know for sure which database encoding is the database using through mysql console?

  16. #41
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @sphinks
    Please read the whole topic. The problem was that PHP used "latin1" instead of UTF-8, and that the HTTP request data was in ISO-8859-1. The DB used "utf8_general_ci" all along. Your procedure (a nice one to note BTW, so thanks for dropping in) is only applicable if the DB has another encoding.

    @co.ador
    Again, if removing the data is feasable - forget about everything else, and remove it. You don't want to have any helthcare problems (headaches, nervewrecks, depressions, etc.) in this economic climate . Not to mention that you'd lose time, and still come out without learning much (if anything at all).
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  17. #42
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    it is very complicated I have tried everything but not to erease the whole data to avoid that. yesterday I created a new table beside and left the one damaged intact and tried to repopulate everything in utf-8 in the new table to test. But still it didn't display the strange character i will go ahead and erase the whole data tonight it will take me a while. I have change the VARCHAR and TEXT fields to utf-8_general_ci and all the tables the database to utf-8 ad utf-8_general_ci but nothing has resulted nothing different I think the character codes underneath won't change unless I do it over again.

    I have a question I have a labtop but I don't ALT+0225 you can achieved those strange character but it doesn't work on this labtop. I tried to change it in Clock, LAnguage and Religion in the control panel to United States International but it didn't result can some body help me to configurate so the keyboard of the labtop is able to type this characters ?

  18. #43
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have done a new database and it is rating now it is storing the rating data but look how...

    In the browser it display like

    Pesuas instead of pesuñas

    In the search bar it display like pesu�s

    it is storing in the database like

    Pesu�s 127.0.0.1 3 2009-08-14

    and in the database the shoe name is pesuñas There should be something in the code which is not passing the data very well...

  19. #44
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Guys look what I have found

    I have put little script below in the code to see what kind of charset is the scrip using
    PHP Code:
    <?php
    $link    
    mysql_connect('localhost''root''coloso'); 
    $charset mysql_client_encoding($link);

    echo 
    "The current character set is: $charset\n";?>
    And this is what it display

    "The current character set is: latin1"

    I have the database in mysql set to utf-8 and I don't know why it is displaying through the script above that it is set to latin1?

    I want to know if the script above it's displaying the character set of the database or the one of the script because the DB is set to UTF-8_general_ci and all the tables and TEXT, and VARCHAR fields to utf-8_general_ci

    I don't know why it is displaying Latin1 through the script above.

    Well I am glad to know that there is a conflict now between latin1 and utf-8 and that's what cuasing now to displaying some character which I have input in the database such as ú,á,é,í etc..

    I am glad just need some of your help now to set up the script to utf-8 thank!!

  20. #45
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Didn't we talked about that already?

    * Once you connect to your DB, use mysql_set_charset().

    * Explicitly send an HTTP Content-Type header with UTF-8.

    * Make sure that the encoding of the file itself is UTF-8. See above for instructions on how to do it in Notepad and Dreamwaver.

    Those second two are applicable for any file that has the potential to contain UTF-8 characters (except application/xml files... those use UTF-8 by default). The first is applicable to any PHP file that connects to your DB.
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  21. #46
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excelent guys The connect to your database mysql_set_charset

    was missing.. even with the old database is working everything is in utf8

    This test below

    <?php
    $link = mysql_connect('localhost', 'root', 'poliferico');
    $charset = mysql_client_encoding($link);

    echo "The current character set is: $charset\n";?>

    result in utf8 not latin1 like before all that resulted after I have mysql_set_charset to ('utf8', $connection) at the connection

    But now the item name is storing with strange character in the database, it is displaying well in the browser, "pesuñas" but once I rate and it is entered in the database from the browser it display like "pesuñas" it seem like the database is not recieving in utf8 or the script is not sending in uft8..

    But thanks now it is displaying and rating... the only issues is as above now

  22. #47
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excelent guys The connect to your database mysql_set_charset

    was missing.. even with the old database is working everything is in utf8

    the test below
    PHP Code:
    <?php
    $link    
    mysql_connect('localhost''root''coloso'); 
    $charset mysql_client_encoding($link);

    echo 
    "The current character set is: $charset\n";?>
    result in utf8 not latin1 like before all that resulted after I have mysql_set_charset to ('utf8', $connection) at the connection

    But now the item name is storing with strange character in the database, it is displaying well in the browser, "pesuñas" but once I rate and it is entered in the database from the browser it display like "pesuñas" it seem like the database is not recieving in utf8 or the script is not sending in uft8..

    But thanks now it is displaying and rating... the only issues is as above now

  23. #48
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now it is displaying and rating perfectly the only thing is that when i rate it the item name "pesuñas" is being stored as "pesuñas" in phpmyadming. it seem like the database is not recieving in utf8 or the script is not sending in uft8..

    Thanks now at least it is displaying and rating... the only issue is as above now

    I have to say that the rating system uses an independent connection of the one used by the other web pages. The rating sytem is an object oriented script which uses the code below
    PHP Code:
    $ratingData Rating::OutputRating($platename);
          
          if (
    Error::HasErrors())
          {
            echo 
    Error::ShowErrorMessages();
            
    Error::ClearErrors();
          }
          else
          {
            echo 
    $ratingData;
          } 
    to display and store the data. as I said it uses an independent database connection and might be set to recieved and send utf-8 data.

    This system uses a database, error, and rating class to work...

    I think because of it's individualization of the website pages, database connection, mysql_set_charset and other functions maybe it is outputing and storing the data in the database in another charset.

  24. #49
    SitePoint Zealot boen_robot's Avatar
    Join Date
    Apr 2008
    Location
    europe://Bulgaria/Plovdiv
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    phpMyAdmin is a separate web app after all. As long as YOUR app gets, sets and displays everything correctly and is UTF-8 encoded, it's all fine.

    And yes, when you insert data into the database, you also need to set the charset as UTF-8. Every time you connect to the database, you need to explicitly speify UTF-8 as the encoding. Regardless of what you'll be doing once you connect to the database. No exceptions.

    As for the phpMyAdmin issue, it occurs because phpMyAdmin seems to be configured to display pages in another encoding (I'm guessing ISO-8859-1) by default. To configure it otherwise, use the language dropdown on the login screen or manually add "?lang=en-utf-8" as the query string.
    XML_XSLT2Processor - perform XSLT 2.0 transformations in PHP.
    (my library, all feedback welcome)

  25. #50
    SitePoint Wizard co.ador's Avatar
    Join Date
    Apr 2009
    Posts
    1,054
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As for this class I refered above, it will be a little more difficult to figure out where to specify to INSERT data into the database as utf8 since now it deals with objects headache for me...

    Well

    take a look at the database connection that this object oriented rating system uses...


    PHP Code:
    <?php
      
    require_once("error.class.php");
      require_once(
    "database.class.php");
      require_once(
    "rating.class.php");
      
    Database::Initialize("mysql""localhost""3306""cara""root""colozar");

    ?>
    I don't have not idea where to mysql_set_charset(). to utf-8 I guess it would be inside the "database::initialize" method

    the initialize method is as below and it is inside a file called database.class.php

    PHP Code:
      public static function Initialize($varType$varHost$varPort$varDatabase$varUsername$varPassword)
          {
            
    Error::Initialize();
            
            if (!
    self::ValidDatabaseTypes($varType))
            {
              
    Error::LogError("Database Type Invalid""Database Type must be one of: " self::DB_TYPES);
            }
            
            
    self::$host         $varHost;
            
    self::$port         $varPort;
            
    self::$type         strtolower($varType);
            
    self::$database     $varDatabase;
            
    self::$password     $varPassword;
            
    self::$username     $varUsername;
            
    self::$savedQueries = array();
            
    self::$savedResults = array();
            
    self::$connection   self::ConnectToDatabase();
            
            
    self::SelectTheDatabase();
          } 
    The SelectTheDatabase() method below
    I add the mysql_set_charset('utf8',self::$connection); the only differences here is that I need to add the word ""self" which is the database class name call database and it worked... though with some issues now it is inserting as utf8 Just like you said All the time you have a connection has to specify the type of charset either inserting or calling information out of the database..
    PHP Code:
        private static function SelectTheDatabase()
          {
            switch (
    self::$type)
            {
              case 
    "mysql":
              
    mysql_set_charset('utf8',self::$connection);
                @
    mysql_select_db(self::$databaseself::$connection) or Error::LogError("Database Selection"mysql_error(self::$connection));
                break;
            }
          } 
    I was wondering the language dropdown to avoid this rare displays inside phpmyadim. It is very strange phpmyadmin is displaying "ISO-8859-1" when I have all set up to utf8 well I guess the utf8 just apply to the database itself.. because there is obvious a conflict among character set once the data is return again to the database through the object oriented rating system.

    The rating system INSERT query looks as below and it is found in a file called the Rating.class.php

    [PHP] public static function RateItem($varItem, $varRating, $varClasses)
    {
    $newClassNames = $varClasses;

    // Verify $varName was provided
    if ($varItem != null && strlen(trim($varItem)) != 0
    && $varRating != null && strlen(trim($varRating)) != 0 && is_numeric($varRating)
    && $varClasses != null && strlen(trim($varClasses)) != 0)
    {
    // Check if Magic Quotes is ON
    if (!get_magic_quotes_gpc())
    {
    $varItem = addslashes($varItem);
    }

    // Check to see that the user has not already rated this item
    if (Rating::CheckRatingsByIp($varItem) == 0)
    {
    $ipAddress = $_SERVER['REMOTE_ADDR'];

    Database::ExecuteQuery("INSERT INTO `rating` (`item_name`, `rating`, `ip_address`, `date_rated`) VALUES ('{$varItem}', {$varRating}, '{$ipAddress}', NOW())", "InsertRating");
    Database::FetchResults("InsertRating");
    Database::FreeResults("InsertRating");
    Database::RemoveSavedResults("InsertRating");

    // Information for the Output
    $averageStars = Rating::CalculateAverageRating($varItem);
    $newClassNames = "rated " . Rating::ShowStars($averageStars);
    }
    }
    else
    {
    // This is a major issue. NOT enough information was sent to log the item
    Error::LogError("Variable(s) Missing", "You must provide all of the information to log the rating of this item.");
    }

    // Build Name/Value Pair to return
    $nameValue = "classes={$newClassNames}&item={$varItem}";
    return $nameValue;
    }[/PHP



    Thank you for explaining I am slow and sometimes I need an explanation twice that's just me at the moment... second language don't catch it right away...

    There are some defects still I will get to you later on I am going to work


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •