jay5r

Given that I'm trying to get other people (who aren't all that technical or patient) to explain the problem to me, using the default theme would be really difficult. But let me look into that a bit more… Someone who is having problems got back to me with the following: I'll continue to let you know as I learn more.

I just had a user report the same problem with Safari on an iPhone 14, so this may not be a problem with older browsers. I've asked for a screenshot and what country he's in since it doesn't seem English is his first language (hence the local date formats may differ from those in the US - even though what the browser is supposed to submit should be standardized).

OK, I'll write a Javascript to test whether a format-based placeholder helps. And FYI - date inputs are only fully supported by ~75% of browsers, with another ~20% having partial support… https://caniuse.com/?search=date input

Date inputs revert to text inputs in older browsers. In those cases telling the user the proper format is essential since the browser isn't formatting it for the user. Can you tell me the format you're expecting on form submission? (YYYY-MM-DD is the most dependable in my experience, but I don't want to make the assumptions that it will work in this case.) I can test this pretty simply by writing a Javascript that changes the placeholder value, but I need to know a format that will work.

One thought… The input element looks like this… Older browsers may not know how to handle date inputs properly. And your placeholder value is "Birthday" rather than a proper date format. Perhaps the solution is to change the placeholder value to specify the correct format (e.g. YYYY-MM-DD, or whatever) so that users with older devices get it entered correctly.

Here are further details about the one Android user I mentioned above.

As I mentioned, I keep asking, but almost no one gets back to me with their details. Not sure what more I can do.

I've been having this problem for quite a while now - through several version upgrades (I always upgrade pretty much immediately). That said it was a trickle of people a month or two ago, now it's at least 1-2 people a day complaining - so the situation is getting worse. It's been difficult to get real responses back from people when I tell them it's probably some sort of browser problem and tell them to be especially careful entering the year (not sure if that means they did manage to register or they didn't). But I did get the following response that might be helpful… BTW, I'm using IPSFocus' Villain theme, if that has any bearing on things. (They pointed me here.)

Define "corrupt". This would be all I'd have to do to restore the data… INSERT INTO `core_stream_subscriptions` (`id`, `member_id`, `stream_id`, `frequency`, `sent`, `added`) VALUES (2,99547,1,'daily',1642337822,1636000819),(8,101722,4,'daily',1642265420,1642351820); I've verified that the members and the streams exist.

I can say that 4.6.10 didn't fix the problem. It started before I did the upgrade and didn't go away with the upgrade. I just looked at my backup and I do have the data. I could restore it pretty easily.

Just thought you guys should know that there are instances where the cron job can go crazy and apparently get into an infinite loop. It does a lot of this query… /*bzone::bzone::IPS\core\Stream\_Subscription::sendBatch:40*/ SELECT DISTINCT *, core_members.last_visit FROM `core_stream_subscriptions` LEFT JOIN `core_members` ON core_stream_subscriptions.member_id=core_members.member_id WHERE frequency = ? AND sent < ? and last_visit > ? ORDER BY sent ASC LIMIT 0,50 Backing up a bit, a couple weeks ago I noticed that load and CPU usage on my server doubled suddenly around January 16th. One of the symptoms was that there were frequently 2 php threads using 50% CPU each (and MySQL was using far more CPU than normal as well). Based on what my host told me I knew they were cron jobs for IP.Board. When I'd watch the queries that were running in MySQL everything seemed pretty normal. Anyway, finally I took a closer look at the queries that were being called and realized that query above shouldn't be called so frequently. I checked and I only had 5 `core_stream_subscriptions` records. Then I noticed two of them had `sent` values that were old. One of them corresponded with the date when the problem started, so I deleted those two records and my server went back to normal. Unfortunately I didn't delve further before deleting the records, so I'm not sure what exactly about those records were causing the problem. Anyway, you might want to look into situations that can cause infinite loops that constantly call the SQL above.

As I'm working with my host - this does seem to be the issue. It's possible the cron jobs for IPB are being kicked off under a user other than what Apache uses. The other issue is they've found a bad (mirrored) drive that could be slowing things down. In at least one case the post was seen. It got into the RSS feed and was visible on a site that uses the feed. It was a while ago and I forget now whether it was visible on the IPB site. Other cases didn't get into the feed, however. Yes, as I mentioned responding to Runar - my host may have set up the cron job under a different user. Does it matter to IPB what user the crons for IPB are run under? So for now things MIGHT actually be OK. I'll wait to see if things return to normal after the drive is replaced. And thanks for everyone's input!

Geez. How did that horrible "feature" get turned on? Only a spammer would like that feature. So that explained one of the problems. Thanks.

I have two instances of IPB on my server. Both are now having (different) security issues… A bit over a month ago we noticed that spam posts were being inserted into `forums_posts` on one of the sites. Curiously the vast majority of them weren't visible to end users, so the attack wasn't all that successful. It was easy to find the spam posts because `author_id` was always zero (and there are no deleted users on that site). I probably should have followed up here, but didn't get around to it. Fast forward a couple weeks and the Mail Bouncer application I use on my other IPB install stopped working properly. The developer had told me how to call it from outside IPB and it started returning "internal server error" messages. Again, I didn't get around to contacting the developer to figure out the problem. Yesterday I noticed that the load on my server and the server's CPU usage had both doubled starting a bit over a week ago. I dug a bit further and saw that there were one or two suspicious threads using a lot of CPU. I run php using FPM and they were running php without FPM. And they weren't running under the user account that web requests typically use. I had my host investigate and they said they were associated with a number of IPB applications for the install where I was having problems with Mail Bouncer - Calendar, Galleries as well as Mail Bouncer and Delete My Account. The idea that someone can insert data into IPB apparently without going through the normal user interface is bad enough. Now seeing that IPB applications can be used to run rogue PHP threads under a user that IPB shouldn't have the password for - is even worse. And yes, we're religious about applying updates in a timely manner. There's plenty of other code on the server (Wordpress, custom PHP, etc.) but IP.Board is the common thread for these problems. I'm working with my host on this. But if Invision has comments/suggestions, I'm all ears.

I'm seeing quite a few posts being held for moderation and wondering what I'm missing. I wouldn't say it's a majority of new posts, but enough to be noticeable. Automatic moderation is off The option for holding new posts for moderation is NOT checked for that forum section The user does not have any infractions that would result in their posts being held for moderation It's happening even to long-term members with high reputation scores. What else could trigger a new post being held for moderation?