tbclark3

I installed the 2.0.1 update. It didn’t do anything catastrophic, but it also doesn’t complete the migration–just spins forever, showing 0/1 projects migrated, even though I reinstalled the old version and deleted the one project.

Is there any way of completely removing wp project manager and starting over? I removed the wp_pm and wp_cpm tables, but it still tried to do a migration. I haven’t tried looking through the wp system tables to see what else needs to be removed. I hope there is an easier way.

When I reactivated the plugin, it didn’t cause the same disaster (no access to anything under wp_admin), but it also doesn’t work. I just got the former version off of backup and replaced it. It correctly shows the one existing project. I deleted it, and upgraded. This time the upgrade didn’t kill the server, but it also still attempts to upgrade the 1 (presumably non-existent) project and never finishes. I have uninstalled it again.

Same problem here. Today’s update caused a server error for anything under wp_admin. I didn’t know which plugin at first, so I renamed the whole plugins directory, then reactivated one by one. wp project manager broke the site again when I reactivated it. It also says it is upgrading the database, but it doesn’t ever finish, and doesn’t show any projects.

What I mean by “over engineered” is that you are overriding the user’s decision about legitimate IP addresses when there is no basis for doing so. My logs show both 172.17 and 19.1 subnets for connections from my LAN. Docker usually chooses 172.17, and I chose 10.1. However, it could easily have been the other way. Had I already been using 172.17, I would have configured Docker to use something else, possibly 10.1. You should not, and cannot, make any assumptions about the validity of IP addresses based on whether they are routable or not. My environment, like many, would have non-routable addresses originating from the LAN, and routable addresses originating from the WAN. In addition, almost all of them show a 172.17 address as the REMOTE)ADDR because all of the packets come through Docker.

I think it would be reasonable for you to offer an option of “Auto” meaning that you would make decisions on the fly about which address is correct. However, if I select HTTP_X_FORWARDED_FOR, it should remain that way, no matter what it contains.

Additional info:
I realize that it isn’t the default that is the problem, and I’m not sure what is. My database did not get upgraded, and it didn’t have a phone_number_digits field. When I added the field manually, it is working again.

SOLVED

The problem wasn’t line length, although it is correct that line length violates a standard. The problem is that Google Calendar rejects any event in which there is a comma in the name of the location. I don’t know whether an unescaped comma in the event location name violates a standard, but it definitely violates Google. Hopefully this post will save somebody else a couple of days of experimenting.

I could leave out the description, but I don’t think it’s possible to add a filter to break long lines into short lines.

Sorry for a second post, but this one is to add two URLs:

ICS file that fails: https://tacomaago.org/events.ics

icalendar validator for this failed URL: https://icalendar.org/validator.html?url=https://tacomaago.org/events.ics

This validator returns a warning for each DESCRIPTION line that is longer than 75 characters. No other warnings appear.

My question is about the widget, not the shortcode.

Thanks for your thoughtful responses, and all the time you put into it. Here is some additional info:

1. This WP instance is running under Docker, and that may be unusual, but I can’t be the only one, and I don’t see how that could be causing the problem. The Docker kernel is a limited view of the system kernel, and the system kernel is running UTC. The Docker container is “correctly configured” to use Pacific time because both /etc/localtime and /etc/timezone are symlinked to the host’s /usr/share/zoneinfo/America/Los_Angeles. The time and timezone info in the container is exactly as it should be. The timezone is correctly configured in WP.

2. I disabled all of the plugins except AMR users, and the problem doesn’t change. The theme is twenty fourteen, a default theme.

I really like AMR Users, and don’t want to switch to a different plugin. I like the configuration screen, and the format and appearance of the user list. It’s better than anything else available. I do like your proposal of eliminating the cache, and I totally agree it’s better to spend your time on that. It will be a lot cleaner without the cache.

I am not allowing users to sign up for my site. They are added and updated programmatically. I will just add a wget to run the “Rebuild Cache Now” from the list configuration page every time I make a change to user data.

Here is an example of a background cache rebuild that I just requested. Note the times. I don’t think this can be any sort of system configuration error. I submitted the request at 2016-06-03 17:23:54 Pacific time. The system logs are correctly showing the localtime.

2016-06-04 00:23:54 – All reports: Cache already scheduled for May 31, 2016 9:33 AM America/Los_Angeles, in 3 days time
2016-06-04 00:23:54 – Received background cache request for 1 reports

One more thing–
Did you figure out that when the log says that a cache is already scheduled, the time it gives is always in the past, but with a positive interval? For example:

2016-06-01 12:17:09 – All reports: Cache already scheduled for June 1, 2016 5:14 AM America/Los_Angeles, in 3 mins time
2016-06-01 12:17:09 – Received background cache request for 1 reports

It thinks the cache is scheduled in 3 minutes, but the actual scheduled time is 3 minutes in the past.

I have two WP instances that use AMR Users–production and test. The production site has plenty of traffic. The two behave exactly the same way with regard to cacheing.

One potential difference is that all of my sites are running under Docker, although it shouldn’t make any difference with regard to time. Within each container, the “server” runs UTC time (which is correct) and localtime is Pacific (which is the same as America/Los_Angeles). The file /etc/timezone is mounted from the overlying server, and PHP is set correctly to use Pacific time.

I have tried all combination of cache settings, and nothing works.

I was having the same problem, and discovered that something, presumably an upgrade, deleted several of my database tables. I am running a multi-site installation, but with only one child site at the moment. Uninstalling and reinstalling Mailpoet did *NOT* re-create the tables. I did not have a reinstall option in advanced options. Finally, in desperation, I went to the master site, and activated Mailpoet and, lo and behold, it created all of the tables–but, of course, as master site tables. I renamed all of them to add the _2, and now it works in the child site.