Skip navigation
Currently Being Moderated

Warning: PHP plans to remove original mysql functions

Apr 1, 2013 5:04 AM

Tags: #php #mysql #server_behaviors #mysqli #pdo

I've posted this in the Develop server-side applications with Dreamweaver forum, but it's worth repeating here because so many people seem to post about PHP problems in this forum.

 

This has been a long time coming, but PHP has now officially deprecated the original mysql functions, as used in Dreamweaver server behaviors, and has announced that they will be removed "in the future".

 

If you're still relying on Dreamweaver PHP server behaviors, it's time to start thinking of an alternative strategy. It's not clear when PHP will remove the mysql functions, but when it happens, Dreamweaver PHP server behaviors will stop working.

 

This doesn't mean you will no longer be able to use the MySQL database with PHP, but you need to convert all your code to mysqli (MySQL Improved) or PDO. It's important to realize that you can't mix the different APIs.

 

Note: this is a PHP decision, not one made by Adobe.

 
Replies
  • Currently Being Moderated
    Apr 1, 2013 5:40 AM   in reply to David_Powers

    Thanks for the update David.  Hopefully this means removal of mySQL functions in DW by CS7.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 6:50 AM   in reply to David_Powers

    Thanks for the heads-up -

     

    Will I need to be make any changes in simple sites using SSI without databases?

     

    For example:

     

      <?php require_once("PCheader.inc"); ?>

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 7:08 AM   in reply to Ken Binney

    You shouldn't need to Ken.  The mySQL functions are a library built into PHP.  It's simply being replaced by a different one.  The full list of changes are found here: http://php.net/manual/en/migration55.changes.php - there are 2 links for incompatibilities and also new features being introduced.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 7:16 AM   in reply to SnakEyez02

    Thanks pal -

     

    Much appreciated.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 8:52 AM   in reply to David_Powers

    David_Powers wrote:

     

     

    This doesn't mean you will no longer be able to use the MySQL database with PHP, but you need to convert all your code to mysqli (MySQL Improved) or PDO. It's important to realize that you can't mix the different APIs.

     

     

     

    1) How complex is it going to be to covert the code?

     

    2) I'm assuming Adobe is ahead of the game and has something already planned to replace the current  database server behavious as that is what makes it a powerful program.

     

    3) will ALL the server behaviours stop working or is it just the one that connect to the database?

     

    4) Hummmm.....if behaviours are just going to stop working overnight when a host upgrade to the next version of php that's going to cause mayhem!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 9:18 AM   in reply to osgood_

    You would only need to worry about conversion on servers that update their PHP version. If you are on shared hosting that may not happen for a long time.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 9:23 AM   in reply to osgood_

    osgood_ wrote:

     

    1) How complex is it going to be to covert the code?

     

    2) I'm assuming Adobe is ahead of the game and has something already planned to replace the current  database server behavious as that is what makes it a powerful program.

     

    3) will ALL the server behaviours stop working or is it just the one that connect to the database?

     

    4) Hummmm.....if behaviours are just going to stop working overnight when a host upgrade to the next version of php that's going to cause mayhem!

     

    Hi

     

    Item 1. This will depend on your current code.

    Item 2. No Idea, (and as you know, anyone who does say anything also has no idea).

    Item 3. Just those that are connected to a database. However PHP 5.4 does make some major changes to PHP, so it will be worth checking.

    Item 4. They will not stop working overnight. Depending on your server-provider, thay may ask you to -

    A. Update your code.

    B. Change to another server-provider.

    C. Move your site to a 'Legacy Server', (this is the worst option).

     

    Why "worst option"?

    Well they may decide that that server will not be updated.

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 10:49 AM   in reply to David_Powers

    Ok folks I've read your replies thanks and need to look into this. Right now I'm none the wiser without doing some extensive Googling on the subject but a bit concerned.

     

    So how would something like the Dreamweaver crap posted below be translated into the new format assuming I was to connect using the follwing mysqli format?

     

    $mysqli = new mysqli('host' , 'username' , 'password' , 'database');

     

    Dreamweaver crap:

     

    mysql_select_db($database_conStarBreaks, $conStarBreaks);

    $query_rsHolidayList = "SELECT * FROM holidays ORDER BY holidayDate";

    $rsHolidayList = mysql_query($query_rsHolidayList, $conStarBreaks) or die(mysql_error());

    $row_rsHolidayList = mysql_fetch_assoc($rsHolidayList);

    $totalRows_rsHolidayList = mysql_num_rows($rsHolidayList);

     

    I can see some kind of tie up - $conStarBreaks above is the variable built up in the DW connections folder so I assume I could replace that with the variable $mysqli, right?

     

    mysql_select_db($database_conStarBreaks, $mysqli);

     

    But are we saying all of the mysql_ stuff is to become defunct - from this point on should not be used?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 10:51 AM   in reply to osgood_

    Hi Os

     

    If you go to my website and download, (and install) the pdo extension it will get you started with using PDO.

     

    The documentation is also on the same page. Sorry about the bad formatting of the documentation, as I had to add the 'open source' info quickly, because people were selling the extension and then users were coming to my site and insisting on help/support.

     

    http://www.pziecina.com/design/dreamweaver/pdo_extension.php

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 11:32 AM   in reply to pziecina

    pziecina wrote:

     

    Hi Os

     

    If you go to my website and download, (and install) the pdo extension it will get you started with using PDO.

     

    The documentation is also on the same page. Sorry about the bad formatting of the documentation, as I had to add the 'open source' info quickly, because people were selling the extension and then users were coming to my site and insisting on help/support.

     

    http://www.pziecina.com/design/dreamweaver/pdo_extension.php

     

    PZ

    Now my brain is scrambled lol.

     

    I'm sort of exploring mysqli at the moement. I have the below that does the identical job to the Dreameweaver stuff I posted above.

     

     

    <?php

    $db = new mysqli('localhost' , 'root' , 'root' , kevtral');

    if($db->connect_errno > 0){

        die('Unable to connect to database [' . $db->connect_error . ']');

    }

    $sql = <<<SQL

        SELECT *

        FROM holidays

    SQL;

     

    if(!$result = $db->query($sql)){

        die('There was an error running the query [' . $db->error . ']');

    }

    ?>

     

    I can loop through the records using he below:

     

    <?php

    while($row = $result->fetch_assoc()){

        echo $row['holidayTitle'] . '<br />';

    }

    ?>

     

    BUT when I put the loop around a <tr></tr> as below it does nothing:

     

    <?php do { ?>

    <tr>

    <td><?php echo $row['holidayTitle']; ?></td>

    <td><?php echo $row['holidayDate']; ?></td>

    <td><?php echo $row['holidayPrice']; ?></td>

    </tr>

    <?php } while ($row = $result->fetch_assoc()); ?>

     

    ALSO why would adding ORDER BY holidayDate (as below) stop things working? Is that not written correct for mysqli?

     

     

    $sql = <<<SQL

        SELECT *

        FROM holidays ORDER BY holidayDate

    SQL;

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 11:45 AM   in reply to osgood_

    Hi Os

     

    Sorry but I have not used the old MySQL or MySQLi  in years, (I only use PDO now).

     

    You best course of action is probably to buy Davis 'PHP Solutions' 2nd ed, or look at the book available form 'Larry Ullman'. Using MySQLi or PDO has little comparison to using Dw's SB's as they are both 'Object Orientated', (MySQLi can be done procedurally, but if you are learning new anyway!) the good news though is that the sql statements themselves can often be retained or easily modified.

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 11:56 AM   in reply to pziecina

    HI PZ,

     

    No worries I sorted most of the issues out by trial and error. It's all good now. I'm already begining to think this is a lot cleaner and simpler than the overbloated code produced by DW.

     

    What I might do is see if I can convert a site I've just finished using sql_ to the improved sqli stuff and see how I go. I think it will be a good few years yet before sql_ gets finally confined to the dustin, but its good to get ahead of the game, starting from now.

     

    Thanks

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 12:28 PM   in reply to David_Powers

    Hi David the below actually worked just fine. I had another instance of the -> fetch line on the page above it which I think was stopping it from working initially.

     

    <?php while($row = $result->fetch_assoc()){ ?>

    <tr>

    <td><?php echo $row['holidayTitle']; ?></td>

    <td><?php echo $row['holidayDate']; ?></td>

    <td><?php echo $row['holidayPrice']; ?></td>

    </tr>

    <?php } ?>

     

    I hear what you say. Looking at the website I'm currently working on which relies heavily on the sql_ stuff it would be quite extensive to go through it and change all of that. I might do it at some stage after the site has gone live just as an experiment and see what kind of a muddle I get myself into.

     

    I'll check out your book....I've got a couple, which I still refer to all of the time.

     

    I've never much liked the server behaviour code DW writes anyway. Could never understand it. Looked to me to always be bloated and more than required so have recently been looking at more hand coding it that area to get more familar with what is happening.

     

    I'm off to watch Jonathan Creek now lol

     

    Thanks

     

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 2:07 PM   in reply to pziecina

    Hi PZ,

     

    Although I have been in possession of your extension, I have chosen to use MySQLi mainly because I saw this as being a natural PHP extension. As such, I imagine that it would be maintained within the PHP/MySQL framework.

     

    I know that PDO is  flexible in that it can be used for other databases; but in reality we usually stick with MySQL.

     

    Please give me your reasons for choosing PDO. It is still early stage and if I were to change my mind, I would love to do so now.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 1, 2013 6:34 PM   in reply to David_Powers

    Thank you David. Your explanation confirms my thoughts.

     

    However, there is still no clear reason (in my mind) to use one or the other. I already have an indecisive better half and now I am adding to our woes.

     

    As far as Oracle discontinuing MySQL, I have been thinking about MariaDB.

     

    MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle

     

    Life is wonderful!!!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 1:55 AM   in reply to Ben Pleysier

    Hi Ben

     

    The main reason that I use PDO is because I do have to connect to different types of databases, and learning one method in php, is much easier that learning three different methods in three different server side languages.

     

    When David says -

    "However, you need to recognize that you won't be able to access all the native functionality of each database system. You'll also need to restrict yourself to generic SQL, or to rewrite the SQL queries for different systems.".

     

    Depending on how you read what David has written, full database access is possible. It is not possible if one uses some of the database library's provided via the php site for pdo, but if you are using one of the major 'players' such as Microsofts SQL, (MSSQL) or the Oracle database, then they provide there own librarys for using with PHP's PDO, which do allow full functionality and access to all database functions.

     

    What David is I think pointing out, is that if one uses SQL database specific statements then these are not transferable to other databases, and this is where good documentation of the code is essential.

     

    PZ

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 3:36 AM   in reply to pziecina

    Thank you Paula,

     

    I have been researching the subjects (one of the latest submissions) and am satisfied with the use of MySQLi rather than PDO. I am basing my preference on the fact that I am confronted with only  one database, namely MySQL.

     

    I really appreciate both your's and David's inputs.

     

    Ben

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 5:29 AM   in reply to Ben Pleysier

    Thanks for the link Ben......need to get my head around that from now on.

     

    Hummm ......just finished up a project using sql_ BUM! Never mind it'll have to do for now, hopefully I won't be around when it stops working

     

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 5:49 PM   in reply to David_Powers

    We have removed the Bindings, Server Behaviors, Components, and Databases panel, as well as Spry,

    Not to forget ADDT!

     

    I know that these are old technologies, but they could have been upgraded long ago.

    As we move forward we will continue to focus Dreamweaver on modern web standards and technologies including HTML5, jQuery, and more.
    This is a forward step for DW; has been mainstream for others.

     

    Where is the facility for working with frameworks such as Foudation 4 and Twitter Bootstrap?

     

    When will we see enhancements like SASS/Compass and LESS?

     

    When will we see compression and minimisation modules for HTML, JS and CSS.

     

    I get the impression that Adobe regard DW as a freebee in a design suite, not as a professional standalone tool for development.

     

    Note: The above has been excreted in anger by a grumpy old man. Hopefully it will not sway younger more ambitious developers away from what is basically a good (read: handy) product.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 9:50 AM   in reply to David_Powers

    David_Powers wrote:

     

    osgood_ wrote:

     

    1) How complex is it going to be to covert the code?

    I've been helping someone in the server-side forum, and remember seeing logout code obviously generated by Dreamweaver that uses session_unregister(), which has already been removed from PHP 5.4. My advice would be to start planning to replace all server behavior code now.

     

    Hi David,

     

    I can't see 'session_unregister' used in associaton with the 'logout server behaviour' code that DW produces: (maybe an early version perhaps?)

     

    This is the DW logout code below, it's using - unset($_SESSION['username']);

     

    // ** Logout the current user. **

    $logoutAction = $_SERVER['PHP_SELF']."?doLogout=true";

    if ((isset($_SERVER['QUERY_STRING'])) && ($_SERVER['QUERY_STRING'] != "")){

      $logoutAction .="&". htmlentities($_SERVER['QUERY_STRING']);

    }

     

    if ((isset($_GET['doLogout'])) &&($_GET['doLogout']=="true")){

      //to fully log out a visitor we need to clear the session varialbles

      $_SESSION['username'] = NULL;

      $_SESSION['password'] = NULL;

      unset($_SESSION['username']);

      unset($_SESSION['password']);

     

      $logoutGoTo = "logout_successful.php";

      if ($logoutGoTo) {

        header("Location: $logoutGoTo");

        exit;

      }

    }

     

     

    Just been playing around with mysqli connection and replacing/adapting the USER AUTHENTICATION behaviours.

     

    Got rid of all the bloated 'login' stuff and replaced it with much more streamlined code (after connecting using mysqli)

     

    <?php

     

    $username = trim($_POST['username']);

    $_SESSION['username'] = $username;

    $password = trim($_POST['password']);

    $_SESSION['password'] = $password;

     

    $sql = 'SELECT * FROM users';

    $result = $conn->query($sql) or die(mysqli_error());

    while ($row = $result->fetch_assoc()) {

    if ($row['username'] == $username && $row['password'] == $password) {

    header ('Location: password_secure_page.php');

    }

    }

     

    ?>

     

    I'll have a go at streamlining the 'log out' stuff later because that looks overly bloated and more complex than it needs to be to me.

     

    Now I've had a chance to assess this in more depth the DW server behaviours ARE as is being said by those with more knowledege wildly outdated BUT their significance as part of the DW toolbox is/was huge. Not replacing them is going to hurt Adobe badly.

     

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 11:33 AM   in reply to David_Powers

    David_Powers wrote:

     

    osgood_ wrote:

     

    I can't see 'session_unregister' used in associaton with the 'logout server behaviour' code that DW produces: (maybe an early version perhaps?)

    Quite likely. I remember seeing it recently in code that somebody posted in the server-side forum. Even though the code had been updated by Dreamweaver, the person asking the question was probably using an old version of the program. That's one of the dangers of the server behaviors: putting too much trust in the program to take care of everything for you.

     

    Ok, that's probably why I'm not seeing 'session_unregister' then.

     

     

    David_Powers wrote:

     

    That's certainly one way of doing it. However, you're running a security risk by creating the session variables before checking the user's credentials,

     

     

    Oooopps am I. Can you elaborate a bit?

     

     

    David_Powers wrote:

     

    and do you really want to store the password as a session variable.

     

    I was checking that both the username AND password had been set on the secure login page which required a the password to be stored as a session variable.

     

    I guess there's really no reason why I need to check to see if the password has been set because if the username isn't set the same results would occur, failed login.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 11:44 AM   in reply to osgood_

    Thats all working good, as you say no need for the password to be stored in a session variable. Why did DW do this if its not necessary, any idea?

     

    Also you say

     

    `Another point is that you're mixing the procedural function mysqli_error() with an object-oriented connection. It won't work, because mysqli_error() requires the link as an argument. (It's not causing a problem because the SQL query is succeeding.)'

     

    How am I doing that?

     

    I'm using this to connect:

     

    <?php $conn = new mysqli('localhost' , 'root' , 'root' , 'donations'); ?>

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 11:56 AM   in reply to David_Powers

    David_Powers wrote:

     

    osgood_ wrote:

     

    David_Powers wrote:

     

    That's certainly one way of doing it. However, you're running a security risk by creating the session variables before checking the user's credentials,

     

     

    Oooopps am I. Can you elaborate a bit?

     

    Your script immediately assigns the username and password to session variables before checking if there's a match in the database. So, even if the login fails, the user would be able to access password-protected pages. They wouldn't be automatically redirected, but they would definitely be able to access pages by going to them directly.

     

     

    Right, that's dumb, won't be doing that then.

     

    Cheers

     

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 12:28 PM   in reply to David_Powers

    David_Powers wrote:

     

    osgood_ wrote:

     

    Thats all working good, as you say no need for the password to be stored in a session variable. Why did DW do this if its not necessary, any idea?

     

    It didn't. The Log In User server behavior creates two session variables:

     

    $_SESSION['MM_Username'] = $loginUsername;

    $_SESSION['MM_UserGroup'] = $loginStrGroup;

     

    The first stores the username. The second stores the user's access level, if required. By default, the server behavior doesn't use the access level.

     

    Yes, just looked. Good so can forget the password session variable, completely unecessary.

     

     

    David_Powers wrote:

     

    Your script has this:

     

    $result = $conn->query($sql) or die(mysqli_error());

     

    It should be this:

     

    $result = $conn->query($sql) or die($conn->error);

     

    Didn't see that change.

     

    So you say:

    (It's not causing a problem because the SQL query is succeeding.

     

    What SQL query? I'm not seeing any SQL query in the code just mysqli???

     

    So are you say this is a SQL query?

     

    mysqli_error

     

     

    OK I think maybe the penny has just dropped. I've been using this:

     

    $sql_2 = 'SELECT name FROM donations';

    $result_2 = $conn->query($sql_2) or die(mysqli_error());

     

    When I should have been using this:

     

    $sql_2= 'SELECT name FROM donations';

    $result_2 = $conn->query($sql_2) or die($conn->error);

     

    Yah I think thats it and a couple of less () to concern myself with.

     

    If it was I was given a bum steer by a tut I was following.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 7, 2013 12:44 PM   in reply to David_Powers

    David_Powers wrote:

     

    osgood_ wrote:

     

    What SQL query? I'm not seeing any SQL query in the code just mysqli???

     

    So are you say this is a SQL query?

     

    mysqli_error

    SQL stands for Structured Query Language, which is used by all relational databases to insert, update, delete, and select data stored in the database.

     

    "SELECT username, password FROM users" is a SQL query (or statement).

     

    MySQL is the name of a relational database system. MySQLi (MySQL Improved) is the name of a PHP API for communicating with the MySQL database.

     

    The mysqli_error() function is part of the procedural (as opposed to object-oriented) interface of the MySQLi API. It requires as its argument a reference to the link created by mysqli_connect(). You're using the object-oriented interface:

     

    $conn = new mysqli('localhost' , 'root' , 'root' , 'donations');

     

    Therefore, you need to use the object-oriented property to display the error:

     

    $conn->error

    Thanks David for the clarification.

     

    Blimey theres a lot to take in isn't there lol.

     

    I think I've got the right combo now. Grrrrr was thrown a curve ball from an online source  I was following which was using this - die(mysqli_error()); instead of die($conn->error); as part of the query.

     

    Suits me down to the ground as I was having trouble remembering die(mysqli_error()); but as $conn (or whatever the variable is for the connection) is part of the query it makes it easier.

     

    Os

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2013 6:33 PM   in reply to osgood_

    Adobe have obviously had a roadmap for Dreamweaver from the outset to become a design and layout tool - They've gradually been downscaling and not updating support for developers.... ADDT went first, when it should have been developed further, now the servers behaviors are on their way out, Adobe say because they're outdated, YES that's true because you Adobe made the decision to let them become outdated.

     

    Where's the development in dreamweaver for MySQLi or PDO? How many hours have Adobe put into that if they're serious about keeping it as a developmt tool?? ..... Third parties have already worked on PDO extensions/support for Dreamweaver but Adobe with all it's resouces and might have done what so far?? Can only be one reason for this - Adobe want Dreamweaver to be design/layout tool and care not about it as a developer tool.

     

    Macromedia Dreamweaver/Ultradev used to be a about a community all pulling together to help make the best web design & development tool out there, now it's just about what Adobe want to do!!

     

    It would just be nice if corporate Adobe were transparent and honest becasue for small developers it's hell,  you clearly don't give a sh*t about the small guys.

     

    Hope one day to see a new Macromedia rise, a dedicated web deisgn/develpoment software company, not a jack of all trades and master of none that Adobe have become!!

     

    P.S. Fireworks rocks - the best web graphics tool ever my a million miles !!

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 18, 2013 1:12 AM   in reply to Energize

    Energize wrote:

     

     

    P.S. Fireworks rocks - the best web graphics tool ever my a million miles !!

     

    I agree BUT you do know that Adobe have already taken the decision to phase Fireworks out as well don't you?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 18, 2013 1:23 AM   in reply to osgood_

    osgood_ wrote:

     

    I agree BUT you do know that Adobe have already taken the decision to phase Fireworks out as well don't you?

     

    I know ... it's a terrible shame, I still have Fireworks 8 on my laptop, it's great for doing basic common web graphics jobs. It's light, fast, easy to use ... as soon as Adobe got hold of it became like all adobe software, bloated and slow, other than tighter compatability with Photoshop which was handy I saw little development of Fireworks under Adobe ...

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 18, 2013 1:32 AM   in reply to Energize

    Energize wrote:

     

    osgood_ wrote:

     

    I agree BUT you do know that Adobe have already taken the decision to phase Fireworks out as well don't you?

     

    I know ... it's a terrible shame, I still have Fireworks 8 on my laptop, it's great for doing basic common web graphics jobs. It's light, fast, easy to use ... as soon as Adobe got hold of it became like all adobe software, bloated and slow, other than tighter compatability with Photoshop which was handy I saw little development of Fireworks under Adobe ...

     

    I have Fireworks CS6 and will keep it going for as long as is possible. Eventually I will have to find an alternative when the OS doesn't supprt it any longer (unless I retire first). It is a great shame because as you say Fireworks is a purpose built software program for web graphics, quick and intuitive to use. Illustrator and Photoshop are cluncky and bloated, combining both DTP and Web...it can't be good. It's like introducing DTP facilities into Dreamweaver, madness. BUT Adobe have obviously done their homework and they say not enough people are using Fireworks to make it financially viable for them to continue developing it any longer.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (2)