Jump to content

Community

prupdated

Members
  • Content Count

    150
  • Joined

About prupdated

  • Rank
    Member

Recent Profile Visitors

9,979 profile views
  1. Random avatars I am back to using for new members work out like this ( selects from about 200 ):
  2. That would be good if it were built in to IPS. Right now it's pretty simple on nginx, with a few image_filter lines. So if you want a 250x250 (or whatever size) version of /image.jpg in the URL, you just call /250x250/image.jpg instead. Something that simple would be good to have to keep image sizes from being too large. Although, you have to be careful not to resize the same images in too many places. Then the client doesn't have the cache of all the sizes so it can be counter productive.
  3. I'd say that's some valuable feedback then is to at least generate a thumbnail image for these. That explains why earlier I saw blank thumbnail entries in the database for all of these which is how I wound up finding this topic. I used to use a random avatar assignment script to do all this. I turned it off and went with this new method. But, I didn't realize this was going on. That might be another idea or feedback, is to allow a pool of random avatars or something else be selected instead of letters. In any case, the letters are now off for me. I'm back to giving new memb
  4. So there is no thumbnail being created for these avatars?
  5. 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.
  6. 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 gav
  7. 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 hol
  8. I've worked in the server IT departments of some very large companies before. There's no way we would jump on a major release like this until probably 6-12 months at the earliest. There would be a vocal set of internal customers who would want it immediately for whatever new features it has. But as the 'server guys' we have to support it. Once we put it out, and it breaks, we own it now. There are also a hundred and one unintended consequences that nobody foresaw - we have support tools, customers have third party apps they use, etc. I don't think it's unreasonable at all to expect at least a
    Very nice. Good to see moods back.
    Very nice layout for a more visual look rather than the traditional text based layout.
  9. 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 count
  10. 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 rev
    Great. Members love this design over the default forum look.
  11. 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.
    One of the most popular plugins on our board for a long time. Glad to see it with 4.X.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy