lance2j

Seems that everybody is having the same problem right now.

I just had the same question about making the featured image in a list clickable. Most users are now instinctively clicking on images to go to another page.

Hi Roland,

I saw where you had made a similar suggestion elsewhere. It’s on my list, but I hafta get in touch with GoDaddy to resolve the lack of cache controls in my WP-Admin.

Take care,

Lance

OK, this has got me to thinking: If, when I originally installed Directory Tools, I gave it a URL slug of “figs” and I changed it to “fig-varieties”, could the change have been made across the board except where the User Favorites is looking? The search list and records favorites are working fine, just not the user favorites page.

Roland, As far as I can tell, it’s happening to all users. But here’s a new chain of logic for you to follow:

I create a new test user.
User goes to User Favorites page
Page displays the message: Please log in to see your favorites.
User logs in
Page now displays: You have no favorites selected yet.
User goes to search page, selects a record, and favorites that record
The record is saving the favorite and incrementing the total favorites on the search column
User goes back to User Favorites page
The page displays: Total Records Found: 0, showing 50 per page
So what changed before the new user selected a favorite? Clearly we go from “You have no favorites selected yet.” to “Total Records Found: 0, showing 50 per page”. So the system recognizes that favorites have been selected, but can’t find them?

FIG USER FAVORITES
TOTAL RECORDS FOUND: 0, SHOWING 50 PER PAGE

Roland,
The favorites are being saved. They show up fine in the search list and the record page. They are just not displaying in the User Favorites page.
Lance

Roland,

Everything is looking great except for the User Favorites page. This is what debug gives my when I load the page:

PDb_List::_setup_iteration list query: SELECT p.id, p.variety, p.goto, p.average_rating, p.favorite FROM wp_jysd9h1471_participants_database p WHERE p.id IN (“0”) ORDER BY p.variety ASC

Of course, I don’t pretend to understand what any of this actually means. But it doesn’t look right. It looks a lot like what I get from running the search page:

PDb_List::_setup_iteration list query: SELECT p.id, p.variety, p.goto, p.average_rating, p.favorite FROM wp_jysd9h1471_participants_database p ORDER BY p.variety ASC

So the difference seems to be with the addition of: WHERE p.id IN (“0”)

I’ve checked repeatedly to ensure I’m using the proper shortcode: [pdb_user_favorites template=responsive]

Lance

Personally, though I have a work-around, I would not mark it as resolved. I lost a tremendous amount of data before I realized what was happening. I suspect this will happen to others. It’s clearly a bug that needs to be resolved.

BTW, there is a simpler way, without going directly into the DB, to fix this, but you must be VERY CAREFUL if your fields already contain any formatted text. All this will be lost through the following process, which seems to work most of the time. If your rich text field already contains rich text formatting, you are better off going into the DB and changing the field type manually.

Create your rich text field. Save fields. Then change the rich text field to text (this will strip out all rich text formatting!). Save fields. Change field back to rich text and save fields. Test by adding a large block of text (that would be truncated if the field is in tinytext). If it doesn’t work the first time, try again. I’m now making this part of my process any time I add a new rich text field.

OK, I have reviewed all of my rich text fields directly in the DB and changed them all from tinytext to text. But every time I create a new rich text field, I have to go through the same process. I don’t know if this is happening to others, but, if so, it’s a sure way to lose valuable data if not fixed before importing or adding data.

Update – I changed the “description” field from rich text to text, then back to rich text (now shows as text instead of tinytext in DB). It now seems to be working for that field. Will hafta do the same for the other rich text fields.

OK, set “Use WordPress Auto Formatting” to “None”. No difference, even when I re-add the data. Looked directly at the database “description” field data. It’s truncated as well. However, there was a field after the “description” label that said “tinytext”, the same as my standard text fields. Disabled ALL plugins except for the four I have from you. No difference. Changed theme to Divi. No difference.

So, everything has been eliminated or changed except for my hosting provider (GoDaddy). The only other constant I have at this point are the four plugins from xnau. I’m at a loss.