Atahualpa Settings file - Sorry but doesn't appear to be a valid ATA Settings File
 

If I export my ATA settings - and try to reimport them - then I get - Sorry but doesn't appear to be a valid Atahulapa Settings File error notice.

Also I have a blank empty line at the top (my site is openmtbmap.org) - which I only managed to make smaller via
margin-top: 0px;
padding-top: 0px;
- but not eliminate...

Also I cannot even Reset all Themes Options - it doesn't do anything. So something must be pretty broken in my Settings (I of course went through each settings page clicking on Save already). My main problem is Mobilegeddon and the current Settings not respecting to decouple the sidebar correctly. It is decoupled but instead of been added to the bottom - it is added even further right (even though the settings themselves are fully correct - I use them on a second page nearly identically - velomap.org):


Settings File is attached (to long to include with Code tags).

you left out a basic peice of information - what version of Atahualpa? (and WP)

oh sorry - up to date WP (4.1.1) and ATA 3.7.22... (been using the ata profile since 2010 I think).

I just imported your settings into Atahualpa 3.7.23 with no issues.
you might want to disable all your plugins to see if there is a conflict

Too Strange - for me I cannot reimport it back. I tried deactivating all plugins - but that doesn't change anything.

I can import the settings of my similar site - velomap - without problems though (attached it here - strangely it's much bigger than my openmtbmap ata settings). Oh and sorry - Reset all settings did work, but not "delete BFA_ATA4" entry in database.

Should I manually delete all bfa_ata references in my database and then try again?

so you have two sites - site1 and site2
site1 exports but does not import
site2 exports and imports correctly

backup site2 and try importing site1 into site2 then you can import site2 back into site2

OR

do it on a test site.

Site 1 Exports - but I cannot Import Site 1 profile either on Site 1 or Site 2.
Site 2 Exports / Imports just fine.

Okay - I found out some more things!

1. Deleting BFA_ATA4 in my database DOES NOT RESET ALL My Options - it puts them to a rather old standard!

So please tell me where did Atahualpa save it settings over the last 6 years and is still reading them in! I must have some old atahualpa options still configured in my database. I don't get why the import of another config works (still doesn't resolve the old bloat) and not reimporting what I just exported. But there clearly are problems with some old stuff. The websites behaves differently to my Site 2 with the same config (e.g. on custom CSS inserts regarding "responsive design" css inserts).


Also some other problems are apparent. If I set CSS file to be external - it loads fine on Site2, but not on the broken Site1... If internal it's fine.. (both sites use the same plugins, are on the same server, use the same nginx rules - and so on).

Oh year - also if I Import Site2 Profile into Site1 - it imports. If I export it - it Exports. But if I try to Import the new export - it fails...
I tried to analyse the change with SVN - but cannot of course at is all a single line...

okay - I advanced a bit. I deleted all "bfa_ata_" options from wp-options table. Now my site is a big mess - but I will manually restore all option fields for now in order not to import any rubbish... Then let's see.

Well I have no clue what is going on. By resetting all Atahualpa options via myphp admin - I was able to get rid of all bugs - and allow for proper reset.

Not working is still the delete bfa_ata_4 command - and I still cannot import the following export (from Site1 - Site2 works fine, but also on Site2 I cannot import the Site1 export).


The reset options really should load default values - and not the values from old bfa_ata_ entries. I do consider this as an bug - though not many people will be affected (only those who still have those old keys in the database).

(as I cannot open this file for reimport - I don't want to try to reset everything - then export to see if the export is broken - which I assume it is even after everything is reset).

Forgot: I'm also still left with the bug that setting CSS File to external - is not working. But I don't care too much about that one.

well I just imported that export fine. and I exported it and attached is the export - try importing it to your site1

Your Export imports just fine... (again I don't really know how to compare it to my export)...

so can you - after importing my export - do an export/import?

I just compared the two files (your export and mine) I did a global change of every comma (',') to a return. The difference I found is your file begins with an unprintable character. A hex FF FE - why I don't know, but that is the only difference.

No - I cannot. Now that you tell it and after I switched on showing all symbols - I can also see that invisible character...
- I got no clue how it gets there...

You could always edit the file and delete that character . Try this:
open the file in a TEXT editor. press the right arrow key once - did the cursor move? if not press the delete key and save teh file. That may get rid of theat character. Then try an import.

yeah - now that I found out about the character - it's easy... - still I have no clue how it happens. (even stranger that you can import it just fine, while I cannot import it - but maybe that's due to your editor not copying that character - while mine does).
Well Atahualpa overall is behaving strange - the responsive settings only work 80% of the time. How it comes that sometimes they work, and sometimes not (without any real pattern) - I don't undestand. In 20% of the cases the viewport does not get correctly defined - and the sidebar goes from 200pixels to 150pixels width and floats away some pixels (and I did not define that anywhere).

Edit: found out why it was going crazy. I had a wordpress core file saved in UTF-8 with BOM. So the BOM got prefixed to the site breaking everything. (make sure to have correct encoding everywhere - and make sure to get EOL correct too everywhere - those two things can really break wordpress)