jptoews

Thanks for the prompt response! Unfortunately, that did not resolve our issue. If you look at the previously-linked page, nothing has changed. I re-saved FileAway settings, re-saved the page in question, cleared the cache… nothing.

Ah, fantastic! I will do that, thanks. Much appreciated.

Also, if it makes any difference, I did pay for a Plus license.

I have deactivated all plugins, cleared and disabled cache, then re-activated *only* NextGen. The same error message appeared immediately.

I’m not keen on switching the theme for testing at the moment, because doing that has caused me grief in the past. I am using Aggregate from Elegant Themes.

If someone from Photocrati is willing to log in and take a look, I’d be more than happy to give you admin access or whatever is necessary.

I should have mentioned this in my first email: I gave the user ALL rights when I created it. I have verified this since. That does not appear to be the problem.

Yeah, sorry, typed off the top of my head. But hopefully it successfully conveyed my question. Ah, I also forgot to put the code tags around it. Fail all the way around.

I am having the same problem. Setting “Add hidden images” to NO resolves the display problem, but that’s not a good solution; I *do* want the user to be able to navigate through the entire gallery in the lightbox.

We were having the same issue, and I eventually found the answer. We are using a child theme, with a modified index.php file. The query to retrieve the products on the home page has changed slightly since we created that child theme (for one thing, they are now declaring a global $product in each query). Once I updated the parent theme to the most recent version (we are using Woo’s “Sliding” theme), and then updated the index.php file in our child theme to use the current query format… the Free! problem went away.

Hope that helps someone…

I re-wrote the VB script that I was using to clean/export from Excel, adding div tags around the contents of each cell. Re-imported into TablePress, set the column widths in the TablePress Custom CSS as you suggested:

.tablepress-id-2 tbody .column-11 div {
width:300px!important
}

et voila! I can now control the column widths.

Thanks for the suggestions and assistance.

SO CLOSE! That works… but only on the first page of results. As soon as you view the next page, that first cell is no longer visible, and the columns revert back to their default widths.

I suppose I could use a script or something to put div tags around every value in the columns I want to resize…

Or perhaps “freeze” one row at the top?

Bummer. That did not change the behavior. CSS-defined width is still ignored, and the header/column alignment still gets messed up.

For the moment, I’ve returned to the basic shortcode with no parameters, and disabled the custom CSS. But if you have any other ideas, I’d love to hear them.

Sincere thanks for all the time you’ve spent trying to resolve my problem.

Brilliant! Yes, that produced exactly the behavior I was hoping for. Thanks very much, Tobias.

Sadly, that does not work; the column width does not increase to 300px, and the header/column alignment is also thrown off…

https://dev.studiotwo.com/jttest/sample-page/

There is an overall width (1410px) and individual column widths being written into the code, which my css styles can’t seem to override.

Option 2 is exactly what I want… but it doesn’t seem to work for me. I changed the column number to 0, since I only want to search the first column (name), but no matter what value I enter in the Search field, I get a “No matching records found” message.

Just in case, I tried changing the column number in your code to various other columns, then tried to search for values that I know exist in the specified column. Every search returned the “No matching records found” message.

You can see the table here:

https://dev.studiotwo.com/jttest/sample-page/

I should really clarify: After running the merge function, every attempt to reach the site displayed the WordPress Installation page. After an hour or so of panicky googling, I found a similar report (unrelated to your plugin) and tried the listed solution: log in to phpMyAdmin, run a check and then a repair on the db. That fixed my problem, and the site is live once again.