prupdated

Bing seems happy with the way things are: In Google, the site has practically been buried.

My sitemap has everything in it. It's updated daily. Still I got slammed pretty good. Years ago, I probably had 90% of my sitemap indexed. Now it's less than 10%. Nothing much has changed with the actual type of content. I've had ssl for years. And redirects from that have long since cleared. So Google basically says most of my site isn't worthy of it's index. In the old days, it would be the other way around - 900k submitted and 850k indexed. I don't think a special formula of sitemaps and meta tags are the ultimate fix here. It appears to just be Google deciding what's important. The burden might just fall on the webmaster doing something their content versus Google's algorithm. Here's a pretty decent article going into the Fred update with some ideas on what to do about it: 3 Examples of Impact From the March 7, 2017 Google Algorithm Update (AKA Fred) https://www.gsqi.com/marketing-blog/march-7-2017-google-algorithm-update-fred/ Also see the Goole Quality Rater Guidelines: https://static.googleusercontent.com/media/www.google.com/en//insidesearch/howsearchworks/assets/searchqualityevaluatorguidelines.pdf

I think it’s just Google doing it’s ‘thing’. I’m pretty sure this has little to do with sitemaps. I process all my sitemaps each night with a simple in-house script for my 500k or so topics. It only takes a few minutes to run. I have been doing it this way for years. All the links show up in Google as being in the sitemap. But about a year ago, Google started dropping them from the index by the hundreds of thousands. Also my home page key words used to be in the top 3 at Google, now they've been lowered into obscurity. It’s not blacklisted. Some links are still there but just not ranking. Yet, if I post something on YouTube or set up an empty store on a popular ecommerce site, all of a sudden those links are up at the top of some search results. So, it may just be Google on yet another new algorithm deciding who gets to see what.

Hi. Overall it looks pretty good except that I have 70,000 members and the script times out if I publish (60 second php timeout). It works on smaller groups. I haven't tried but it might work if I don't publish but wait for cron to pick it up. Although, I'm concerned what could happen if it is already timing out on the front end publish. Also, I'm not sure how long it would take using sparkpost since I don't see a settable sending rate with sparkpost. SMTP has a rate option but I run into some problems with SMTP on spark post from time to time. Any help would be appreciated. Thanks.

The 4.1.14 update was one of the most disruptive updates to my site in the last year or two. Immediately after updating I got tons of complains about members not being able to login and other issues. I have been running Easy Pages for quite a long time. I also experienced some of the same issues noted above. It didn't stop with the Easy Pages app either. There were many other problems - all of which worked fine before 4.1.14. At first, I was able to partially work around the new login url problem by doing some server based rewrites / redirects. Ultimately, more problems surfaced and I gave up and converted what Easy Pages I had to the regular Pages app. It seems over time, the Pages app has added much of the Easy Pages functionality to it anyway. This was still hard because many of the features I used it for I had to change or get rid of completely during the migration. After this, I had to uninstall Easy Pages. Then I also had to reset my Furls to defaults. Then recached the site. This fixed most of the problems. User logins were now working properly rather than retuning error pages. However there were still problems unrelated to Easy Pages. It seems after resetting Furls to defaults, there were a few native IPS calls still using the old format that were not reflected in the new default Furls. So I had to go into the source code and work around those. And second to last of my problems, a number of url formats I used for custom theme changes previously were now broken - such as calling a topic with just a dash after it and nothing else now required two dashes. And the last present of 4.1.14 was some type of IPS search index task update that caused my sql server to nearly lock up so bad it caused my website to timeout while it was running. After a few days, I was able to isolate this as the problem and just set my site to only index 3 days of data so it would calm down this problem. There is a thread about this problem elsewhere on the forum. So what went from a seemingly routine IPS incremental update, turned out to be the nightmare of the year for me. All told it probably took me a week to sort out the mess. I will certainly take all updates very seriously from now on with full backups done immediately before so I can immediate roll back and research when this type of thing happens again. I will also likely skip many of the updates since they can cause so many problems. As it is, it has become more common to find an increasing number of plugins and updates and template changes and urls breaking on each IPS update. I can see why the cost to develop modifications for IPS 4 has gone up. Their shelf life may be only as long as a few weeks until the next update. At the same time, the number of modifications and functionality / performance of the forum software itself are a mere fraction of what used to be available in the IPB 3 days. For crying out loud, to this day I still have to rely on using a Google search for indexing my forum rather than the built in high performance Sphinx searching of days gone by.

Same problem here. I was able to work around it for now by editing this file: /applications/portal/extensions/core/FrontNavigation/Portal.php changed line reading: class _Portal to class _Portal extends \IPS\core\FrontNavigation\FrontNavigationAbstract I assume it has to do with some menu issue in 4.1 like is shown in one of the patches to 4.1.7 that refers to this type of error. I'm not sure if this workaround causes any other problems, but this at least got me going on 4.1.7 and easier than restoring back to 4.1.6.1. If you haven't upgraded yet, I would hold off until it's fixed though.

location /api/ { rewrite ^/api/(.*)$ /api/index.php; } Seems to be working (adjust for your directory structure as needed). I used the sample script here: Which outputs as expected (replaced name and url): php testapi.php { "communityName": "name", "communityUrl": "url", "ipsVersion": "4.1.6" }

Thanks for the suggestion. I tried it before but search is lost on archived topics. Generally it would be a good idea except for the functionality loss. The load times now are fine while not losing the functionality when archiving. It was just the size of an individual forum that was the problem. Hence, moving topics could be a decent solution for this and other problems, maintenance, or many other reasons why one might want to bulk move. I've worked around it for now doing my best with SQL scripting to move older topics out of the main forum each night while updating the various related counters. Most likely I'm missing something though. So it would be nice to have an official routine.

This should really move up the priority list. I have a forum with nearly 4 million posts and 600k topics. In IPB3, the size of the forums didn't seem to matter. In IPB 4, the site chokes up and delays about 2-3 seconds every time someone would click on a forum with a large number of topics in it. By large, I mean several hundred thousand topics and millions of posts. Clicking on a smaller forum is no problem and happens fast. This is a 12 core server with 32 GB of RAM running at 3.2 GHz, MariaDB, etc. and various optimizations, CDN, etc. The only way I could even use IPB4 without reverting back to IPB 3 and reconsidering my alternatives, was to chop up the forums into smaller ones. The main forum being about 50k topics max. Most likely the way I do it is not the best through various SQL statements. But to keep the site moving with sub second load times, I push out topics over 90 days old into an annual forum. I know there's an archive option, but the last time I tried that I didn't like that it took those topics out of searches and member's history. I'd rather just have an option to move topics to another forum after X days without the archiving.

With IPB 4.1.4 the sort order of portal topics does not seem to work if selecting to sort by topic start time. Rather, it sorts by default of last updated topic no matter what the setting. It worked correctly with IPB 4.1.3.2 . I had to change the sortBy line in portal.php from start_date to forums_topics.start_date and it then works as expected. Edit: Seems to be IPB bug with fix attached at following URL. After reversing my edit and applying the patch it works as expected again.

I'm not getting a PM icon either. The PM is there. Just no icon. Notification settings are set correctly. And a regular PM works as expected. As soon as I send a regular PM to the new member, I get a 1 on the notification icon, and 2 on the PM. Before that nothing. Edit: I'm running IPB 4.1.3.2