slevit

More bad news…

From the shortcut – deleting a file stored in ../user_uploads/ folder deletes row from wp_posts properly, but the physical file is not deleted.

From the dashboard – deleting a file stored in ../user_uploads/ folder deletes from wp_posts properly, but, the physical file is not deleted and the Media Library row persists.

Those are the most obvious. You need to revisit your delete logic between post_types nm_userfiles, attachment (Media Library) and the associated ..wp-content/upload folders.

Fantastic! Requiring File Title’s is great, but it would be a tremendous improvement if they were to default to the actual file name(s) selected. Better still, adding the actual file name to the File’s uploaded grid (shortcode and dashboard) would help greatly too.

I now kinda “get” the idea behind the Add & Edit User Files functionality (via dashboard). But, (1) the storage location should be consistent. Uploading a file from the shortcut goes to the ../user_uploads/ folder, while uploading from the dashboard goes to the WP Media Library. (2) From User Files via the dashboard, the “Add Media” button should be made inoperable once a file is uploaded. It doesn’t make sense to allow multiple file uploads for a single title (even if your programming doesn’t really let it happen).

I’m also perplexed as to why users’ uploads are assessable via the WP Media Library. It seems to defeat the purpose of this plugin.

Finally, the plugin still doesn’t work under IE 11. And, you might want to test the other browsers.

To the extent that the plugin actually works, it only does so under Firefox 31. It doesn’t work at all under IE 11. File selection dialog pops up, but nothing happens after file is selected.

Installed your plugin on fresh, out-of-the-box WP 3.9.2 install. No other plugins installed. Browser cache cleared. SAME RESULT AS REPORTED!!!!!!!

Files DO get uploaded. But, NO files are reported on your “User Files” page. Add New User File from your “User Files” page is 100% confounding!!!

I’ll give it try. Out of curiosity, why do you advise not to “put an editable table editor on your public facing screens using the shortcode!”?

Never mind — I don’t know how this happened but, some how, a old version of /assets/db-table-editor.js (at least) got pushed down when I installed the plugin.

I deactivated, deleted and reinstalled the plugin from WP and noedit_columns is now working as expected. The odd thing is that your last update to the plugin was 7/7/2014. But, my initial install occurred after that date.

Visitors aren’t presented with the SendPress signup form. The site administrator adds new subscribers exclusively. The mistake I made earlier was that I added the new subscribers with a active status.

My latest test, I added a subscriber with a unconfirmed status. I then edited the new entry and changed the status to active. I got the notification email as expected, but ONLY one notification address was specified.

I repeated the test with two notification addresses and had no luck. My conclusion is it works only if a single notification address is defined.

I’m at WordPress 3.9.1 and SendPress (free) 0.9.9.9.3.

Notifications screenshot *disregard the pipe character in the input field.

To test, I entered 2 valid email addresses separated by a comma. I did not wrap the string in quotes. The Notification options are set correctly, but I did not receive a email after adding a couple of new subscribers to a list.

Question: Are the notifications processed “instantly” as the attributes suggest? Or are they scheduled by a cron like job? Either way, I’ve been twiddling my thumbs for a couple-three hours now.

Which version? I’m at 0.9.2 and this bug still isn’t fixed. One line of code doesn’t seem like too big a deal that you couldn’t push down a update today. We’re at your mercy here.

Your welcome. Your plugin has a lot of potential and I’ve got plenty of time on my hands.

If you do want to punish yourself today, you’ll want to merge the “tooltips” (rev. 813002) bug fix. That really needs immediate remediation. The rest is all new functionality. But, the “sortability toggling” (rev. 813015) is good to go as well. The rest is still work-in-process.

John,

I committed a handful of revisions so far, but there is more work to be done before I can give you the green light.

Steve

On second thought, it isn’t necessary to create a thead1. Instead, it would make more sense to position the Table Navigator on a tfooter. To do so would require the following mods to DBViewTable.class.php:

Near line 194, add:
$tfoot = new DBViewString();

Replace line 239 with:
$this->controls->wrap(‘th’, “class=’table-navigation’ colspan=$numCols”)->wrap(‘tr’)->moveTo($tfoot);

Between lines 254 and 255, add:
$tfoot->wrap(‘tfoot’)->moveTo($ttable);