Hi,
I posted this topic in the General a while ago, but still don’t have a solution. Hopefully someone in Backend Issues can help me?
Thanks 🙂
<p>Hi,</p>
<p>I have 8 tabs set up which are all appearing fine.</p>
<p>However i have an issue on save. For example, if i am editing/adding content to Tab 3, once i save/update the page, I am bounced back to Tab 1.</p>
<p>Before Save – Active tab is #3</p>
<p>
</p>
<p>After Save – I’m bounced back to Tab 1</p>
<p>
</p>
<p>Is there a way to stay on the active tab after Save/updating?</p>
<p>I’m not using conditional logic (per this thread), they’re just tabs with basic text fields inside them.</p>
<p>Does anyone know of a workaround?</p>
<p>Cheers!<br>
I am having the same issue. Is there a way to make a feature request?
+1 hope there’s a fix for this soon!
This bugged me a lot. So I wrote a small class to handle this:
https://gist.github.com/gchtr/2d371918f3778683c61f629dbc545972
Whenever a tab is selected in a post, a transient containing the current tab index is saved via AJAX. When a post is loaded, it checks the transient and selects the last selected tab via JavaScript.
Hopefully, a proper solution for this will soon be implemented into ACF.
Thanks for sharing your solution gchtr!
Thank You gchtr, this is awesome !!!
Hi @gchtr, Thanks for sharing this solution!
I hope Elliot will take it in consideration as a starting point for a final solution.
I think that selection of acf tabs should happen only if you are saving the post.
Your solution will store the last opened tab and open it every time I open the edit post. It a great starting point, and I’m just using it. But I suppose that should works something like this:
1. When I click on an acf tab this tab is stored in a hidden field.
2. When Saving post this field is stored (or sended to next query ?? ).
3. When reloading the edit post screen if this value is stored in the database it will be get and removed from the db, just for using it only one time.
Hey @virgodesign
I also hope that there will be a solution implemented into core.
You are right, the solution provided also sends an AJAX request when you open a post for editing, which is unnecessary, because the first tab is always selected by default.
I optimized the code a little, so that it only sends an AJAX request when it’s really necessary. It won’t send one on startup, only if a different tab is selected.
https://gist.github.com/gchtr/2d371918f3778683c61f629dbc545972
The solution currently saves the index as a transient, which is valid for 5 minutes. I like your idea of using the value just once and then deleting it right away. I added that to the gist as well.
Saving the current tab in a hidden field and store it in the database when saving a post might be the better solution, but it needs a little more effort to implement. I prefer the quick and easy fix here, because I don’t consider it to be a permanent solution.
+1 for a core implementation.
I don’t think that the last opened tab should be saved in the database. I think it should only be for the current session of editing. For example, if I click “Edit Page”, it should always go to the first tab. But after I made an edit on a tab section and click “update”, it should remember which tab that was.
I have tried the fix but i guess it doesn’t seem to work with Option Page.
@gchtr thanks for improving your solution.
We hope Elliot will take in consideration to improve this feature asap, and the idea of using an hidden field to let wordpress remember last active tab.
Thanks for throwing a solution out there. Unfortunately, this doesn’t seem to work on front-end forms. Hopefully Elliot finds time to add this in soon.
+1 for the core implementation. actually, +1000. 🙂
A little late here, but an easy JS solution I created is this:
jQuery(function(){
function parseHash(){var hash=window.location.hash.substring(1),params={};if(hash.length<5){return params;}var vars=hash.split('&');for(var i=0;i<vars.length;i++){if(!vars[i]){continue;}var pair=vars[i].split('=');if(pair.length<2){continue;}params[pair[0]]=pair[1];}return params;},
var hashData=parseHash();
if(hashData&&hashData.acf_tab){jQuery('a.acf-tab-button[data-key="'+hashData.acf_tab+'"]').trigger('click');jQuery('form#post').attr('action','#&acf_tab='+hashData.acf_tab);}
jQuery('a.acf-tab-button').on('click',function(event){window.location.hash='&acf_tab='+jQuery(this).data('key');jQuery('form#post').attr('action','#&acf_tab='+jQuery(this).data('key'));});
});
Just add that anywhere in the admin area of your site through an action/filter. Here’s an example of that for your functions.php file:
add_action( 'admin_enqueue_scripts', array(__CLASS__,function(){
wp_enqueue_script( 'psAdminCustom', get_template_directory_uri() . '/admin/custom.js', array(), '2.0.0', false );
} ) );
Good news! With the new PRO version 5.6.6 this feature has finally landed in Core.
It works great so far. It sets the currently active tab in Local Storage when the page is unloaded. As far as I can see, there’s no logic yet that unsets the setting at a certain time, so as long that value is in Local Storage, it will load the same tab.
I think in most cases this is great, but would love the ability to turn this off on certain groups. Would much rather a revisit to the page showed my “Content” tab rather than the “Customize” tab.
The old functionality is desirable in many applications.
@enfueggo Did you figure out a way to disable this?
This is my best solution so far;
//select first tab by default
add_action('acf/input/admin_head', 'my_acf_input_admin_head');
function my_acf_input_admin_head() { ?>
<script type="text/javascript">
jQuery(function($){
$('.acf-tab-group li:first-child a').trigger("click");
});
</script>
<?php }
@jusxon I do something similar but actually like your method mimicking the click a bit better than mine of adding and removing classes. Still hoping this becomes an option some time in the future.
