1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

One site lost? (error=Undefined offset)

Discussion in 'Sitebuilder 4.1 for Linux' started by ovaleye, Jan 25, 2008.

  1. ovaleye

    ovaleye Guest

    One as-yet-unpublished site on my server suddenly stopped working. The site was almost complete. Selecting Preview Site now only displays the generic start wizard screen, and selecting Edit Site In Wizard produces the following error:

    Internal SiteBuilder error.
    File: /usr/local/sitebuilder/include/SB/Helpers/Wizard/Edit/Page.php; Line: 68
    Message: PHP Notice : Undefined offset: 0; Code: 8

    All other sites on this server are working fine. The owner of the lost site reported no odd behavior during the last edit session. Looking around in the Sitebuilder files I can see that raw site files still exist for this site in htdocs/sites, so I don't think the site is really lost.

    Any ideas about how I can bring this site back to life?
  2. ovaleye

    ovaleye Guest

    After numerous hours of trying to figure out how this thing works I may have been able to answer my own question, but I can't be sure. If anyone knows if this is the right answer please let me know.

    I ended up examining the MySQL tables carefully and found that the 'site' table is linked to the 'site_page' table through the 'site_page_id'. For this particular site the 'site_page_id' had no matching records in the 'site_page' table. There were a number of records related to the site though, but I was confused to see that the related records had several different 'site_page_id' values. In fact it appears that most of the sites had several different values, and I couldn't be sure of the relationship between the 'site_page_id' in the 'site' table and the the related records in the 'site_page' table.

    For the site in question I decided to try changing the 'site_page_id' in the 'site' table to the lowest value for a related record in the 'site_page' table. Note that the original value was 111 and the lowest related record value was 112. When I tried previewing the site it actually came up (now I'm starting to feel better) but it was definitely not the newest version of the site.

    Searching through the 'site_page' table to find the newest records for this site I found a group of records numbered 336. I changed the 'site_page_id' for this site in the 'site' table to 336. Now a preview of the site looks like it might be right (the customer will have to verify). I have not yet tried the Edit or Publish (I want to make sure the site is right first) but I hope those work too.

    Does anyone know if this fix was the right thing to do?
    Any ideas how this sort of problem could have come about?
  3. ovaleye

    ovaleye Guest

    Well... I still can't say that my solution was the "correct" solution, but it has seemed to work. The once-lost site is now back in operation. The site owner indicated that it has all the most recent changes in it, and it looks like editing in the wizard is working.

    One possible cause: The site owner remembered a message had come up just prior to exiting their last edit session. They pointed out the area they had been working on. When I went there I saw an error message the stated there were duplicate page file names. It would not allow me to leave that page while the error remained. I changed the page file name and all was good, and I verified that another page in the site did have that same name.

    Apparently the site owner just exited the editing session without fixing the duplicate page file name problem, which left the site data in a comprimised state. This is my guess anyway, though I don't really want to duplicate the scenario to verify it. I also do not know how the duplicate page file name would have been created, since it looks like they were just using the default "pageX.php" file names.