I am using WP 2.8.3, Atahualpa 3.4.4, PHP 5.2.4.

When I first set up the blog I was able to go into the the Atahualpa Theme Options and change things like background and font color. One time I went to tweak a font color on the Body, Text & Links page and when I clicked the big Save Changes button the page reloaded and it said "Atahualpa settings reset." at the top. All of my styling changes in that section were lost. I have since tried making on other pages and the same thing happens. I notice that the URL always comes back with "reset=true" in it. Can somebody explain why this is happening?

I think my sysadmin was making configuration changes on the server around the time this happened. Could it be a permission issue? I've looked at the PHP and HTML code and I can't figure out how clicking the Save Changes button is triggering a reset.

Thanks in advance for your assistance.

Bob

wow this is a strange one and the first I've heard of it. Can you swap to the default theme and make changes with it? Do they stick.
Have you added any new plugins in?
Try deactivating tall the plugins and see if it works.
What was the sysadmin doing?

Yes, I swapped to the default theme and changed the color of the header text. It stuck. I've tried other themes and they are working. Perhaps they save their style changes differently. I don't know.

I don't have any active plugins.

I believe the sysadmin was moving the server behind a firewall. I'm not certain. I will check.

Are the styles for Atahualpa written to a db or are they saved in a file. Could file permissions be an issue? I'm sure I'd get some error if it was not writing to file, but that doesn't explain how I end up with the Save Changes button giving me a reset. It's damned annoying. Now anything I try to tweak in Atahualpa loses anything I was previously able to change. It's slowly stripping it back to defaults. Maybe I should just restore all defaults and start over. Still, I can't see how that explains this. I don't know what the code is doing when you hit the save button. I didn't want to start digging before asking.

Bob

I just checked my correspondence with the sysadmin. It looks like they were moving from a physical to a virtual server. I'm not sure what that meant from a configuration standpoint, but I believe there was also a firewall change. I'm confirming.

Bob

First thing to do is a backup of your wordpress database. You shoud also check with the sysadmin to see if they make backups, you might be able to fine ne with everything before you ran into this image.

All the settings are saved as rows in the wordpress database - in the wp-options table.

Pressing the big Green Save, should write that page of options to the database. You could also remove the theme from teh themes folder, get a fresh copy and reupload it. That would make sure it wasn't some kind of corruption of the code.

I'd also do an analyse and repair of the database

I think it's too late for a back-up of the db. I've been banging my head against this for weeks, but I will check. Good to know where it's being saved.

I deleted 3.4.1 last night and installed 3.4.4 but the problem persists.

I'll suggest the analyze/repair of the db, but I'm not sure how that would prompt the reset=true in the URL.

This one just defies logic for me.

Bob

Can you create a new database (I don't know how easy this for you) and do a fresh WP and Atahualpa install and see if the problem is there also. that would tell if it was something on a grand scale.

If the new install works, you could go in and change the 'bad' wordpress's wp-config.php to point at the new database and see if the same issue occurs. If it fails, then it's something to do with the code of file permissions, if it works, then it's probably the DB

I shared your last message with my sysadmin. Here is his reply:

"It has been my concern that perhaps it is trying to write to the filesystem. The reply seems to indicate that file permissions can, in fact, be an issue. If file permissions can *ever* be an issue, then they
are *definitely* causing an issue (or at least contributing to one). The webserver doesn't have the ability to write to any of the theme or Wordpress files.

Can you check on the forum what the file permissions should be? None of the files or directories are currently writable by the Apache process."

Can you help us answer that?

Thanks,

Bob

some plugins and themes need WP-contents to be 755, but Atahualpa is'nt writing anything to the theme folder, only to the database.

I wonder if this could be a php issue with <form method="post">?
this is done in bfa_ata_admin.php

Thanks for the lead. I'll look at the code. I didn't see how permissions could cause the page to change the form action. I'll check out the file you reference.

OK. I'm trying to do a little troubleshooting in the code. I don't program anymore, but I can still find my way around. I see that for it to send "reset=true" in bfa_ata_add_admin.php that $_REQUEST['action'] must equal "reset". I dropped a print_r($_REQUEST) at the top of the page and tried to change the background color. Here's what I got:

Array ( [page] => functions.php [bfa_ata_body_style] => font-family: tahoma, arial, sans-serif; font-size: 0.8em; color: #000000; background: #CCCCCC; [bfa_ata_link_color] => 666666 [bfa_ata_link_hover_color] => CC0000 [bfa_ata_link_default_decoration] => none [bfa_ata_link_hover_decoration] => underline [bfa_ata_link_weight] => bold [save] => [action] => reset [category] => body-font-links )

Clearly this isn't right. Now, when I went to look at the HTML source code I found the problem. I don't know why it's happening, but I'm fairly certain this is it. Below is a snippet from the source code of themes.php?page=functions.php where the save and reset buttons are. Note the closing </form> tags:

<p class="submit">

<input class="save-tab" name="save" type="submit" value="">
<input type="hidden" name="action" value="save">
<input type="hidden" name="category" value="seo">
<span style="font-weight: bold; font-size: 22px; color: #018301">Save settings of current page</span>
</p><br>

<form method="post">
<p class="submit">
<input class="reset-tab" name="reset" type="submit" value="">

<input type="hidden" name="action" value="reset">
<input type="hidden" name="category" value="seo">
<span style="font-weight: bold; font-size: 13px; color: #ab0000">Reset settings of current page</span>
</p>
</form>
</div></form></div>

Now I have NO IDEA why it is generating it that way. Since in bfa_ata_admin.php (line 675) it echos:

PHP Code:

    if ( $value['category'] != "start-here" AND $value['lastoption'] == "yes" ) {  
        echo '<div id="submit-container" class="bfa-container" style="background: none; border: none;">    
        <p class="submit">
        <input class="save-tab" name="save" type="submit" value="" />
        <input type="hidden" name="action" value="save" />
        <input type="hidden" name="category" value="' . $value['category'] . '" />
        <span style="font-weight: bold; font-size: 22px; color: #018301">Save settings of current page</span>
        </p><br />
        </form>
        <form method="post">
        <p class="submit">
        <input class="reset-tab" name="reset" type="submit" value="" />
        <input type="hidden" name="action" value="reset" />
        <input type="hidden" name="category" value="' . $value['category'] . '" />
        <span style="font-weight: bold; font-size: 13px; color: #ab0000">Reset settings of current page</span>
        </p>
        </form>
        </div>';
    } 


I didn't take time to analyze the conditions under which this is being written, but it's the only place in the theme that is writing these buttons.

So, can anyone help me determine why it would be screwing up writing the closing form tags? Again, I have uploaded the very latest version of the code (3.4.4) and this problem persists. It's as simple as a closing form tag. Any help would be appreciated.

I have no idea if it's related, but one other detail that struck me. All of the HTML tags are losing their closing slashes. Is there something "cleaning up" the code? Is that some PHP setting? If so, could that be the problem?

Bob

Bob,
Atahualpa doesn't have a theme.php. If there is one in you Atahualpa folder, that could be part of the problem.

The code that builds the Save/reset options is in bfa_ata_admin.php startng at line 673

When I choose Atahualpa Theme Options from the WP admin panel it goes to: /wp-admin/themes.php?page=functions.php and pulls up the Atahualpa Options page(s).

ok, phew, that's correct.

this has to be something specific about your environment. You are the only one having the problem. hundred of others hit save and it works fine.

If you want, I could download your entire wordpress folder and run a compare against a fresh install, but I still think it is an environmental issue, something to do with where you are running

Have you tried a fresh install of Wordpress and Atahualpa in a new database?

I, too, think it has to be an environmental issue. My sysadmin is going to do a fresh install of everything and we'll see what comes of that. In the meantime I'm configuring the version I have running locally and moving the changes to the wp_options table in the db. Crude, but it works. I want to get this thing launched so I can focus on content.