New Fontsamplers couldn't be created.

[shahabsiavash]

Hi,

Now I can't create a new Fontsampler :( After I create one I get the error: "Failed to create a fontsampler." And there is a empty font set there with [fontsampler id=0]. Every time it is a id=0!

And I actaullty have to create one for tommorow post. Could it be fixed soon?

And the sets couldn't be deleted too.

[shahabsiavash]

Anybody here :(

[kontur]

Since this is probably related to the issues you had with your server roll back it is absolute guess work to figure out what could have gone wrong here. Nonetheless, I'd be curious to implement checks and fixes that prevent a situation like yours. Would it be possible for you to send me a database dump of THE FONTSAMPLER TABLES, so all the tables that are named wp_fontsampler_.... In PhpMyAdmin you should be able to Export, then select those four tables, then select Structure and Data. Make sure to export only those four tables that have data about fontsamplers. You can email me the file at support@underscoretype.com or send as download link here.

[shahabsiavash]

Hi, thanks. I have sent the email. It's strange that the old ones work. Although they couldn't be updated too.

[kontur]

Thanks for the info.

This looks like something with your database restore went wrong, or it is only partially complete in regard to the database table structures. Your previous data is there, but the tables don't seem to have a PRIMARY KEY nor do the id columns have auto_increment, which results in new Fontsamplers having an unusable id of 0, and duplicate as such.

Again, this is not really a Fontsampler bug, but let's see how we can fix it — or instruct your web host to perform those fixes to properly restore the database to what it originally was.

First of all: Take another database backup of your entire site. The info below is given with best intentions and should work, but you are responsible for your data.

In your PhpMySql, in the tables wp_fontsampler_fonts, wp_fontsampler_sets and wp_fontsampler_settings look at the content (Browse tab) and remove those unusable rows that have an id of 0 (in wp_fontsampler_settings it is settings_id — either way it should be the first column). Those should be only content you tried to add since the database restore that went wrong. Next, you need to fix those tables so that new Fontsamplers will be created correctly. For those same tables manipulate the Structure. Edit the id or settings_id column to have auto_increment (this should be shown in the "Extras" in the table of all the columns). Under the list of fields, you need to add a new PRIMARY KEY (there can only be one per table, but it seems your tables have none at all). There should be a field "Create an index on ...1 column [GO]". From that menu, select PRIMARY KEY for column id. When this is done for all three mentioned tables you should be able to create new Fontsamplers with correct ids.

Let me know if that worked. Also, if saving existing ones does not work, do you get any kind of error messages?

[shahabsiavash]

Thanks for the time you put on this. But I'm afraid I don't think I could do all of these. I don't have an experience on this matter and I don't want to wreck what's left of it. But again thanks for checking this issue out.

I still can't understand how this happened. It was a full full backup from the entire host. How some tables aren't there and how there are not there completely after inserting them directly into the database. That is the mystery to me.

[kontur]

Why the database tables would be missing a PRIMARY KEY or other attributes is indeed odd. A backup should be a backup and have nothing to do with the structure of the data. Also, manually inserting a database backup should not affect this, except if the backup itself did not include all the right info, or if some of the SQL statements were somehow incompatible. All those issues, however, are not related to Fontsampler per se, I am afraid.

Fontsampler has some basic database sanity checks. For example the plugin does check that certain database tables do exists, and that the version of the database tables is at the correct version with the plugin. Checking something like PRIMARY KEY or auto_increment settings does not seem practical, since the assumption has to be that if the tables are there the plugin created them correctly. I might revisit this in the future to expand the checks some more, but it seems to be a very niche problem resulting from interference from outside the plugin code base.