Jump to content

Apfelstrudel

Clients
  • Posts

    685
  • Joined

  • Last visited

  • Days Won

    1

Apfelstrudel last won the day on May 20 2023

Apfelstrudel had the most liked content!

2 Followers

Recent Profile Visitors

4,175 profile views

Apfelstrudel's Achievements

  1. https://github.com/disposable-email-domains/disposable-email-domains https://github.com/disposable-email-domains/disposable-email-domains/blob/master/disposable_email_blocklist.conf https://gist.github.com/adamloving/4401361 I don't know if you have considered them yet. I also found a provider of a huge disposable email domains list. https://emailverification.whoisxmlapi.com/disposable-email-domains/
  2. Interesting to hear, but I used Google's top search results for "10-minute emails" or "temporary emails". Maybe I should look on page 10 of the results page to use a lesser known provider. 😄 But seriously now, if the problem mentioned by opentype is like this, then the list of these providers should be optimized 😉.
  3. Hello, today we upgraded to the latest release and immediately activated the "blocking disposable emails" feature. (btw, very good idea 😉) We did three tests with 10 minute or temporary email providers and in every case I was able to finish the registration and confirm my email address. Did I do anything wrong?
  4. Hello Marc, thanks for your help. I already got an email from support. So it was not necessary to start the upgrader.
  5. Where did I say I expected you to start the upgrade? 😉 I just mentioned that it would make some discussions easier if you looked at the problem in the backend right away. Anyway, thanks for your information about the open bug report. We will wait to upgrade until the bug is fixed. 🙂 Just one last question. Will this bug then be fixed in a future version or will the current build be changed? So do we have to skip the 4.7.12 upgrade then? Thanks in advance for a short answer.
  6. Does this mean you are aware of this problem and will fix it? Because I also do not understand what you can not understand about my post. The upgrader could not start because this profile field is missing. Sorry to be a bit direct, but if you, dear Marc, would at least occasionally make the effort to look into the backend, some question loops could be avoided and some questions would not even arise. This is only a small excerpt from the experiences I was allowed to make in the last 5 years 😉.
  7. The profile fields were removed normally via the backend a couple of weeks ago. The upgrade process brings the following error message in step 1: "There are some problems with your database which need to be fixed before you can start the upgrade". Then when I go to "Get Support" in the backend and look at the database error, it brings me the following suggestion: "ALTER TABLE 'ips_core_pfields_content' ADD COLUMN 'field_1' MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL;" Why should I add profile field #1 again when I don't need it anymore? And even if I would run this query, what about the pfields data table that also contains info about the profile fields? Wouldn't that cause other problems? I heard from another forum owner that this could happen because the profile field #1 is defined in install.sql. I didn't see any warning during the profile fields deletion process that we are not allowed to delete field #1 😉.
  8. Hello, we wanted to upgrade to 4.7.12 today, however the database check found a problem before. Apparently it is because the profile field with ID 1 is no longer present. FYI. We recently removed that very profile field because it contained information about AIM that no one uses today anyway. Likewise, we removed some other old profile fields that no one needs anymore. Our instance originally came from a vB import. How to do the upgrade now?
  9. Where are these privacy and PII features here in this community? I can't find them in the "Security and Privacy" section within my profile settings.
  10. Hello Marc, I have to correct myself in this case. Originally we came to the assumption that the archiving stopped because phpmyadmin showed the same number of records over several days. In the meantime, however, it turned out that phpmyadmin with a certain configuration only displays estimated values. Using a SQL count command, however, we were then able to see the correct number, which also increased every 5 min. So the archiving seems to work after all. Sorry for the circumstances. However, it is still unclear why there are posts in the archiving table that were permanently deleted a long time ago (archived_queued=-3). Has the permanent deletion process not worked 100% here?
  11. Hello, Today we noticed that we have some errors in system log daily caused by different widgets. I would really appreciate if you could help me. Thank you in advance for your help.
  12. Dear @Stuart Silvester, I hope my post was not misleading. I have of course taken into account everything that the archive function requires. As I said, there are a lot of topics whose last reply was more than 15 years ago. However, these topics are not archived. I'd be happy to name a few topics in a ticket mail to which this applies. As an addition, I would like to mention that the estimation in the backend after entering the filter criteria gives an estimated archiving level of 49%. So far, however, only about 10% has been archived. I also don't understand why deleted posts show up in the archive even though they were permanently deleted long before. I would appreciate it if you could please take a quick look at our system to identify the problem. Thanks in advance and best regards
  13. I have never used the archive feature before. Never. Yes I know that the condition is based on the last reply. 😉 Look into the db and you will find a lot of examples which match the filter but are not being archived. I permanently deleted all deleted content before I activated the archive feature.
  14. Hello, a few days ago we activated the archiving feature. The only condition we set was to archive topics whose last reply is older than 15 years. Nothing else. Now we have found that the archive task is being run frequently, but it is no longer archiving. We found a lot of topics much older than 15 years, but they remain in the normal database. The only noticeable thing we found was that in the last records of the archive table, the "archive_queued" field is set to -3. I don't know if this is something interesting. Those records only contain content which has been deleted permanently before. @Daniel F or support team: Any idea where the problem might be?
  15. So you think multiplying the mysql timeout by 200 solves the problem 😉. Normally these big tasks are done step by step, like rebuilding the search index. I suspect that you are not doing the entire delete task in one command.
×
×
  • Create New...