[Resolved] Site Migration to new server broke Toolset

[Author]

Posts

[Zach Jones]

I am trying to migrate this site to a new server (BlueHost). Once I complete the migration, one of my views stops working. This view is a custom search view. In the attached screenshot, you can see where instead of showing search fields, it instead shows the shortcodes. I have other custom search views on the site and those are working fine.

This is the only view that is not working on the site. With this view, in the filter editor, I am using wpv-conditional to display a different styled form on two different pages. Both display the same loop output. See code below for example. When I remove the conditional output tags, everything starts working again.

I really need the conditional output tags to work. The site is currently on the original server to prevent users from seeing this error, but the toolset debug information included is from the new server.

How can I fix this? Please let me know if you need more information.

[wpv-filter-start hide="false"]
[wpv-filter-controls]



[wpv-conditional if="( '[wpv-post-url]' eq '<em><u>hidden link</u></em>' )"]<div class="form-group">
<i class="fa fa-bed fa-2x" aria-hidden="true"></i>[wpv-control-postmeta field="wpcf-lm_int1_1" type="select" source="custom" url_param="wpv-wpcf-lm_int1_1" values="4,1,2,3,4,5" display_values="4+,1+,2+,3+,4+,5+"]<i class="fa fa-bath fa-2x" aria-hidden="true"></i>[wpv-control-postmeta field="wpcf-lm_int1_8" type="select" source="custom" url_param="wpv-wpcf-lm_int1_8" values="3,1,2,3,4,5" display_values="3+,1+,2+,3+,4+,5+"]MAX. <i class="fa fa-usd fa-lg" aria-hidden="true"></i>[wpv-control-postmeta field="wpcf-l_systemprice" type="select" source="custom" url_param="wpv-wpcf-l_systemprice_max" values="700000,275000,300000,325000,350000,375000,400000,425000,450000,475000,500000,525000,550000,575000,600000,625000,650000,675000,700000,725000,750000,775000,800000,825000,850000,875000,900000,925000,950000,975000,99999999999999999999" display_values="$700%%COMMA%%000,$275%%COMMA%%000,$300%%COMMA%%000,$325%%COMMA%%000,$350%%COMMA%%000,$375%%COMMA%%000,$400%%COMMA%%000,$425%%COMMA%%000,$450%%COMMA%%000,$475%%COMMA%%000,$500%%COMMA%%000,$525%%COMMA%%000,$550%%COMMA%%000,$575%%COMMA%%000,$600%%COMMA%%000,$625%%COMMA%%000,$650%%COMMA%%000,$675%%COMMA%%000,$700%%COMMA%%000,$725%%COMMA%%000,$750%%COMMA%%000,$775%%COMMA%%000,$800%%COMMA%%000,$825%%COMMA%%000,$850%%COMMA%%000,$875%%COMMA%%000,$900%%COMMA%%000,$925%%COMMA%%000,$950%%COMMA%%000,$975%%COMMA%%000,$1%%COMMA%%000%%COMMA%%000+"][wpv-filter-submit name="<i class="fa fa-arrow-right fa-lg" aria-hidden="true"></i>" type="button"]
</div>[/wpv-conditional]



[wpv-conditional if="( '[wpv-post-url]' eq '<em><u>hidden link</u></em>' )"]
<p class="form-group"><label>[wpml-string context="wpv-views"]<h2 style="margin-bottom:0.1em;">SORT BY:</h2>[/wpml-string]</label>[wpv-sort-orderby type="list" options="field-wpcf-l_listingdate,field-wpcf-l_systemprice" label_for_field-wpcf-l_listingdate="NEWEST" label_for_field-wpcf-l_systemprice="PRICE - LOW TO HIGH" orderby_as_numeric_for="field-wpcf-l_systemprice" orderby_ascending_for="field-wpcf-l_systemprice" orderby_descending_for="field-wpcf-l_listingdate"]</p>

<h2 style="margin-bottom:0.1em;">REFINE</h2>

<div class="form-group">
	[wpv-control-postmeta field="wpcf-lm_int1_1" type="select" source="custom" url_param="wpv-wpcf-lm_int1_1" values="0,1,2,3,4,5" display_values="BEDS,1+,2+,3+,4+,5+" auto_fill_default="1"]
</div>

<div class="form-group">
	[wpv-control-postmeta field="wpcf-lm_int1_8" type="select" source="custom" url_param="wpv-wpcf-lm_int1_8" values="0,1,2,3,4,5" display_values="BATHS,1+,2+,3+,4+,5+" auto_fill_default="1"]
</div>

<div class="form-group">
	[wpv-control-postmeta field="wpcf-l_systemprice" type="select" source="custom" url_param="wpv-wpcf-l_systemprice_min" values="0,0,275000,300000,325000,350000,375000,400000,425000,450000,475000,500000,525000,550000,575000,600000,625000,650000,675000,700000,725000,750000,775000,800000,825000,850000,875000,900000,925000,950000,975000,1000000" display_values="MIN. PRICE,No Minimum,$275%%COMMA%%000,$300%%COMMA%%000,$325%%COMMA%%000,$350%%COMMA%%000,$375%%COMMA%%000,$400%%COMMA%%000,$425%%COMMA%%000,$450%%COMMA%%000,$475%%COMMA%%000,$500%%COMMA%%000,$525%%COMMA%%000,$550%%COMMA%%000,$575%%COMMA%%000,$600%%COMMA%%000,$625%%COMMA%%000,$650%%COMMA%%000,$675%%COMMA%%000,$700%%COMMA%%000,$725%%COMMA%%000,$750%%COMMA%%000,$775%%COMMA%%000,$800%%COMMA%%000,$825%%COMMA%%000,$850%%COMMA%%000,$875%%COMMA%%000,$900%%COMMA%%000,$925%%COMMA%%000,$950%%COMMA%%000,$975%%COMMA%%000,$1%%COMMA%%000%%COMMA%%000" auto_fill_default="0"]
</div>

<div class="form-group">
	[wpv-control-postmeta field="wpcf-l_systemprice" type="select" source="custom" url_param="wpv-wpcf-l_systemprice_max" values="99999999999999999999,275000,300000,325000,350000,375000,400000,425000,450000,475000,500000,525000,550000,575000,600000,625000,650000,675000,700000,725000,750000,775000,800000,825000,850000,875000,900000,925000,950000,975000,1000000,99999999999999999999" display_values="MAX. PRICE,$275%%COMMA%%000,$300%%COMMA%%000,$325%%COMMA%%000,$350%%COMMA%%000,$375%%COMMA%%000,$400%%COMMA%%000,$425%%COMMA%%000,$450%%COMMA%%000,$475%%COMMA%%000,$500%%COMMA%%000,$525%%COMMA%%000,$550%%COMMA%%000,$575%%COMMA%%000,$600%%COMMA%%000,$625%%COMMA%%000,$650%%COMMA%%000,$675%%COMMA%%000,$700%%COMMA%%000,$725%%COMMA%%000,$750%%COMMA%%000,$775%%COMMA%%000,$800%%COMMA%%000,$825%%COMMA%%000,$850%%COMMA%%000,$875%%COMMA%%000,$900%%COMMA%%000,$925%%COMMA%%000,$950%%COMMA%%000,$975%%COMMA%%000,$1%%COMMA%%000%%COMMA%%000, No Maximum"]
</div>

[wpv-filter-submit output="bootstrap" class="fusion-button button-large button-default"][/wpv-conditional]



[/wpv-filter-controls]
[wpv-filter-end]

[Christian Cox]

Hi, I'll be glad to help.
When I remove the conditional output tags, everything starts working again.
- Just to be clear, you've got post URLs used in conditionals. Are the URLs in these conditionals updated appropriately on the new site following the migration? Obviously server1.com/post won't match server2.com/post, but I just wanted to be clear that you've considered that part.
- Add debug="true" to your wpv-conditional shortcodes and copy the debug information from the front-end of the site into your reply for me to review.
- How is this View inserted on the page? In a Fusion Builder design? Placed in a post content? A screenshot showing the shortcode implemented in wp-admin might be helpful.
- If you disable other plugins and activate the parent Avada theme, is the problem resolved? I would like to eliminate outside interference.
- Are any errors shown in the server logs on the new server? If you're not familiar with the logs, I can show you how to activate them. Go in your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to:

define('WP_DEBUG', true);

Then add these lines, just before it says 'stop editing here':

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

Refresh one of the pages where the shortcodes are appearing in the page markup. If any backend errors are generated, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the updates you made to wp-config.php.

[Zach Jones]

Great, thanks. Please see below.

1. Yes, URLs are the correct.
2. See below for debug information. (I've changed URLs to an example URL)
3. View is inserted as a shortcode in a text block element in Fusion Builder. I’ve attached screenshots for both the home page and the page that displays the results that also displays the search fields.
4. If I disable plugins and activate parent theme, this still doesn’t work correctly.
5. There are no errors showing in the error log.

####################
wpv-conditional attributes
####################
Array
(
    [if] => ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
    [debug] => true
)

####################
Debug information
####################
--------------------
Original expression: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
--------------------
After replacing 1 general variables and comparing strings: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
	Comparing <em><u>hidden link</u></em> to <em><u>hidden link</u></em>


####################
wpv-conditional attributes
####################
Array
(
    [debug] => true
    [if] => ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
)

####################
Debug information
####################
--------------------
Original expression: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
--------------------
After replacing 1 general variables and comparing strings: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
	Comparing <em><u>hidden link</u></em> to <em><u>hidden link</u></em>


####################
wpv-conditional attributes
####################
Array
(
    [if] => ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
    [debug] => true
)

####################
Debug information
####################
--------------------
Original expression: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
--------------------
After replacing 1 general variables and comparing strings: ( '<em><u>hidden link</u></em>' = '<em><u>hidden link</u></em>' )
Comparing <em><u>hidden link</u></em> to <em><u>hidden link</u></em>

[Christian Cox]

Okay thanks, I don't see anything obvious here so I need to take a closer look. If it's okay with you, please provide login credentials to your BlueHost wp-admin area in the private reply fields here. I will install the Duplicator plugin to create a clone that I can install on my local environment where I can effectively troubleshoot the issue.

[Christian Cox]

Hi, on my local testing it seems to be related to the %%COMMA%% options in the postmeta control fields. As a quick test, can you remove all the %%COMMA%% placeholders in your wpv-control-postmeta tags in a duplicate View and replace your current working View with the new one? That way you could quickly revert to the working View if the problem persists or another problem is introduced. I will continue to investigate why the %%COMMA%% placeholders are not behaving, but this could help get your site back into a functional state with conditionals.

<div class="form-group">
  [wpv-control-postmeta field="wpcf-l_systemprice" type="select" source="custom" url_param="wpv-wpcf-l_systemprice_min" values="0,0,275000,300000,325000,350000,375000,400000,425000,450000,475000,500000,525000,550000,575000,600000,625000,650000,675000,700000,725000,750000,775000,800000,825000,850000,875000,900000,925000,950000,975000,1000000" display_values="MIN. PRICE,No Minimum,$275000,$300000,$325000,$350000,$375000,$400000,$425000,$450000,$475000,$500000,$525000,$550000,$575000,$600000,$625000,$650000,$675000,$700000,$725000,$750000,$775000,$800000,$825000,$850000,$875000,$900000,$925000,$950000,$975000,$1000000" auto_fill_default="0"]
</div>

<div class="form-group">
  [wpv-control-postmeta field="wpcf-l_systemprice" type="select" source="custom" url_param="wpv-wpcf-l_systemprice_max" values="99999999999999999999,275000,300000,325000,350000,375000,400000,425000,450000,475000,500000,525000,550000,575000,600000,625000,650000,675000,700000,725000,750000,775000,800000,825000,850000,875000,900000,925000,950000,975000,1000000,99999999999999999999" display_values="MAX. PRICE,$275000,$300000,$325000,$350000,$375000,$400000,$425000,$450000,$475000,$500000,$525000,$550000,$575000,$600000,$625000,$650000,$675000,$700000,$725000,$750000,$775000,$800000,$825000,$850000,$875000,$900000,$925000,$950000,$975000,$1000000, No Maximum"]
</div>

[Zach Jones]

Okay, I just checked into this, and it didn't fix the issue for me. I removed all of the %%COMMA%% placeholders and updated both pages to display the test view, but I could only see the shortcodes again.

Were you able to see a full search form on the listings page with a group of checkboxes, sort by field, etc.? These are the fields that are not supposed to display on the homepage, which is why we are using the conditional shortcodes.

I appreciate all of your help so far!

[Christian Cox]

I see, I had also deleted the filters just underneath the NEIGHBORHOODS heading. That's why mine was working but yours is not, I assume. This is quite confusing - if I delete those NEIGHBORHOODS filters, it works. But if I restore the NEIGHBORHOODS filters and delete the two filters under REFINE, it works again! So I'm leaning towards this being related to the total amount of content in the filter area, or the total number of filters, or some other strange edge case. Let me reach out to my second tier support team for some additional assistance here. Please stand by and I will update you when I have some additional information to share.

[Zach Jones]

Thanks Christian! I look forward to your response.

[Zach Jones]

Hi Christian. Just wanted to follow up on the status of this issue. Are there any updates?

[Christian Cox]

Hi, sorry I was out for a few days. I've asked my 2nd tier team for an update on this. Their last communication to me was that this seems to be a complex issue that requires more in-depth investigation, which will take some time.

[Christian Cox]

After further investigation, our 2nd tier support team has determined that it seems that this View's filters have become corrupted somehow in the database, possibly by manual modification of the field shortcode attributes and custom values, or possibly during a migration process. We have not been able to replicate the problem when building similar Views from scratch, and Views with similar filter structures seem to work as expected when built using the Views Filter GUI. When editing the current filters in this View, some filters may completely disappear, and others begin to display invalid information. So at this point, it appears the best solution is to build a new View from scratch, using the same filters, but use the GUI instead of copy + paste to add each filter. Please create a new View using the GUI to add each filter, then insert this new View on your page instead of the current View. I'll stand by for your results.

[Zach Jones]

Hi Christian,

Thanks for the info. I've tried to re-add this view manually, without copying and pasting, and instead using the GUI. It seemed to be working okay until I added the wpv conditional tags. I'm thinking that is what is breaking it. This worked fine on our previous server. Why would the wpv conditional tags not work on the new server? Any ideas? We really need to get this fixed soon so any feedback is appreciated.

[Christian Cox]

Why would the wpv conditional tags not work on the new server? Any ideas?
Did you keep a copy of the site from before you migrated to the new server? That might help us determine whether the root cause was a migration issue or a server configuration issue.

[Zach Jones]

Yes, we do have a copy of the site files and database files from the old server. Are there any specific server settings that I should check for on the new server?

[Christian Cox]

Configurations and settings on the server could be any number of things. The typical ones to look for are listed in our requirements: https://toolset.com/toolset-requirements/, but installing a clone of the old site is the first step to determining whether or not server configurations are part of the problem. If we can install a clone of the old site on a server where it works, then install a clone of the new site on the same server environment, it should work too. If it does work, then we can probably eliminate database migration issues from the possible causes since the data from both sites works on identical environments. Then we need to examine other possible causes.

I will activate private reply fields here so you can share a download link for the old site backup.