Support

Account

Home Forums Add-ons Options Page Options page save redirecting to 404

Solving

Options page save redirecting to 404

    • hrwdevs

    • November 21, 2014 at 11:04 am

    When I hit save changes on my options page it works for a second, then refreshes to my 404 page. It does not update the database. I built the site on a local apache server so the database is currently populated with content and works correctly, but saving changes does not work on the server. I already disabled plugins, switched themes, reset the options page, updated the plugin. Please, any advice on why this may be happening would help.

    I can manually update the database and it will correctly update the content.

  • A 404 will usually happen if the field name of a submitted value uses a WP reserved term. http://codex.wordpress.org/Function_Reference/register_taxonomy#Reserved_Terms

    • hrwdevs

    • November 25, 2014 at 4:20 am

    There were no reserved terms being used. However, I did notice that I had entered some URLs in text fields. So I changed the fields to URL fields. Still wouldn’t submit. So I took the https:// out of the URL and switched it back to a text field. It submitted. So I put the https:// back in front of 1 of the URLs. It again wouldn’t submit. So for now I hardcoded the https:// into my template. Any reason why https:// wouldn’t be allowed to be submitted to DB?

  • I’m experiencing this exact same issue.
    When I enter a url with ‘http://’ into a text field or url field I get a 404 when I save. Works fine if I just enter ‘www.domain.com’.

    This issue only happens in an Options page.

  • Also, the field I’m trying to save is not a WP reserved term.

    • debbie3

    • March 13, 2015 at 4:47 am
    This reply has been marked as private.
  • Same for me, cannot save – it goes to 404. Only on options pages, and only on production site. Working fine on development server and locally.

    It might be an issue with WP 4.1.2 or ACF 5.2.3, locally I see I still don’t have the new version of those two.

    Would love a solution!

  • I have also faced this issue and as a solution I have removed the domain protocol i.e. http: or https: and just used //example.com solved the issue in URL field value.

    You can find further info / help related to this in the link below :

    http://support.advancedcustomfields.com/forums/topic/options-page-not-working-with-godaddy/

    Thanks!

    • jase_io

    • April 29, 2016 at 11:53 pm

    I experienced this issue yesterday on a client’s live site – we tried to update a URL field in a custom options page with a new value and instead of saving the changes, it threw out a 404. The odd thing is that the URL field was working fine in local and staging environments.

    Any ideas? Does anybody know if a fix is being worked on for this?

  • @jase_io what is the name of your URL field?

    • jase_io

    • April 30, 2016 at 2:38 am

    Hi John. There are two fields, one is basket_url and the other is checkout_url.

    Any ideas?

  • I’m guessing that you’re might be using woocommerce. checkout_url is a url query parameter used by woocommerce. Using it as a field name can cause unexpected issues. I’m not saying that this is definitely the issue, but it might cause a problem. To be honest, I’ve never seen this happen with a URL field on any site that I’ve worked on.

    Somewhere along the line it has something to do with some type of redirect or rewrite that’s happening based on the URL being part of the $_POST values that are being sent to the server.

    Can you give me a list of all the plugins that you’re using on the site? I’d really like to try to recreate this just to see if I can. Have you tried deactivating other plugins or changing themes?

    • jase_io

    • April 30, 2016 at 3:38 am

    Thanks for your quick response John. The website isn’t using Woocommerce and it’s not do with the theme or any plugins, I know that much as I developed the site myself from scratch.

    However, to answer your question, the site is using the following plugins:

    • ACF Pro 5.3.5
    • Disable Comments 1.4
    • Yoast SEO 3.1.1

    I’d refer to @jacobajjarapu and @trainoasis‘s comments – it’s working fine in local and staging but not in production. The fields definitely aren’t being used elsewhere. It’s a strange one. For now I’m just going to hardcode the fields as a workaround, but it would be great to know if anybody else is experiencing this issue.

  • I’d like to know what’s causing it as well. There must be something different between the two servers.

  • I’m having the same issue. It never happend with previous versions. And it’s happening in my two websites.
    I wish there was a solution, apart from hardcoding the URLs

  • same problem here. Repeater with url field. Someone figured out how to solve this problem?

  • I’d love to be able to figure this out so that I can help other people with the same issue. The problem is that I have never been able to reproduce the problem on any site.

    1st steps, have you tried deactivating other plugins and changing to one of the default 20XX themes? Does the same thing happen with a basic theme and only ACF installed?

  • I have constantly tested it. This occurs only when using the field type Url and options page. In other fields gave no error. I tested with WordPress Version 4.6.1 and ACF PRO Version 5.4.4. No other plugin installed.

  • I had this happen on one of my site on godaddy after a migration with cPanel hosting. I was able to fix the issue my making them text fields and <a href="http://{{options.twitter}}" title="Twitter" target="new" class="twitter"></a>
    You just need to add instruction to let user know to use only www and not http://. I have several other sites that use the URL version on my social links and I haven’t had problems with those. So I am not sure if its due to host, migration, WP version or ACF version or other issue.

    Advanced Custom Fields PRO Version 5.4.4
    Timber Version 1.1.5

  • When it is reported it is almost always related in some way to migrating a site from one place to another, though I don’t know why. It seems to happen on godaddy more than it happens anywhere else. I’ve never used godaddy, and quite honestly, probably never will. Every time it comes up here, and it comes up a lot, I have tried to recreate the problem and have never been able to do so.

    Some things to check after a migration:

    Look at the values that are store in the database for the option value. These can be found in the wp_options table with the option name "options_{$field_name}" Is the value stored here the same as the value stored on the DB you are migrating from.

    Check the value that is being returned by ACF $value = acf_get_field('my_url_field', 'options'); echo $value;

    Check the field key for the field in the options table. The field key can be found under the options name of "_options_{$field_name}". Id the field key correct? Does it match the field key for the field on the site?

    Are the field keys for the site where it’s working and the site where it’s not the same?

    Personally I have never used or trusted automated migration tools. Since this comes up mostly as something that happens when moving data from one site to another site, my first suspect would be in how the data is getting from one site to the other and looking for what the difference in that data is.

  • It is not Godaddy, I use other server. It is something with “links” field type URL and option page. I did tests with others format field types and works fine.

  • Since I am not seeing any problem with url fields on options pages, I can pretty confidently say that it is not ACF. I was trying to give you some things to look at to figure out why you are having this problem.

    If you’re game, we can do some debugging to see what’s happening.

    Step 1) Open the options page where you are seeing this problem, after the page loads, leave it open in your browser and go on to step 2

    Step 2) Open the file /wp-admin/admin.php, the top of the file will look something like this

    
    <?php
    /**
     * WordPress Administration Bootstrap
     *
     * @package WordPress
     * @subpackage Administration
     */
    
    /**
     * In WordPress Administration Screens
     *
     * @since 2.3.2
     */
    

    After the opening PHP tag and a new line and insert

    
    <?php
    echo '<pre>'; print_r($_POST); die;
    /**
     * WordPress Administration Bootstrap
     *
     * @package WordPress
     * @subpackage Administration
     */
    
    /**
     * In WordPress Administration Screens
     *
     * @since 2.3.2
     */
    

    Step 3) Return to your browser, enter a value that you know is going to cause a redirect in the browser. Click update.

    If the problem is something in WP you will see the posted array output. If you get redirected then the redirect is happening before the page is loaded and is happening on the server level before the updated gets to WP.

    Do the test and let me know what happens.

    • deej

    • October 6, 2016 at 11:16 am

    @hube2

    Having the same issue: Not on GoDaddy hosting, fine on localhost, but redirected to 404 on live when using URL fields on the options page. I have also used this setup on other sites, but not had this problem.

    I attempted your debugging steps; there was no array output, the redirect to 404 occurred. If this is a server-level problem I’m completely stumped.

  • It’s definitely a server level redirect. Do you have access to the .htaccess file on the server? What does that look like, maybe there is something in it that’s detecting something in the submission and attempting to redirect, but that would be extremely odd. If you have access to it can you post the content of any .htaccess files?

    I did find this, but I don’t know if it’s any help. http://wordpress.stackexchange.com/questions/77337/page-returns-404-with-post-variables-but-not-without.

    Finally, what is the exact page url that you end up on that shows the 404?

    • deej

    • October 11, 2016 at 11:00 am

    Hi @hube2,

    The .htaccess has the basic WordPress parts:

    
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    Good idea to check if any reserved names are being used. Looked into the site’s functions and plugins and everything looks prefixed to remove the chances of conflict with reserved names.

    The 404 URL is http://example.com/wp-admin/admin.php?page=example-settings, and the error page shown is our custom 404.php.

    Edit to add: When hitting the Update button on the settings page, usually `&message=1″ is appended to the URL to display the “Options Updated” notice. This doesn’t happen when the URL field error occurs.

    Thanks for investigating, John.

Viewing 25 posts - 1 through 25 (of 36 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.