Jump to content

teraßyte

Clients
  • Posts

    33,811
  • Joined

  • Last visited

  • Days Won

    55

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Invision Community 5 Bug Tracker

Forums

Events

Store

Gallery

Everything posted by teraßyte

  1. Yeah, sorry for the long delay. A few days after I made that post my internet connection went down and it took 2+ weeks to get it working again. I am still catching up with things and this one slipped through. I have already made the change for the search index update, it turned out to be a bit more complicate to research than what I had thought. But in the end the change needed was actually really simple, just one line I'm gonna re-test the plugin on 4.1.11 and I'll follow up with 2 peoples that reported 2 different bugs but never provided me the steps to properly reproduce them. If they don't reply within a couple of days I'll release the update with only this fix.
  2. Yes, the issue with the activity stream is that I am not bumping the time in the search index too. I will have that resolved in the next version. I have just gotten back after being away for 11 days so I need some time to catch up with everything. I'll see if I can release the new version with this fix (and others) this weekend, or the next week maybe.
  3. The lower settings always takes precedence. If a group must wait 60 minutes to bump from the last bump and the other must wait 30 minutes then the user will have to wait only 30 minutes.
  4. Okay, that's the configuration with the 1 week wait. What number did you have before? Also, does the user have any secondary groups? Secondary group settings apply as well.
  5. Yes, it should be. I have this fix on my list for the next release. I've just been so busy that I haven't gotten to it yet
  6. Someone else very recently already mentioned the activity streams too, I have an idea on how to fix that. AS uses the search index so I need to update the time in that table too, unlike 3.4 that loaded the data directly from the topics table.
  7. I'll take a look at the topic/post feed and see what is going on. I think it might be because of the caching going on.
  8. You mean the setting "Last post limit"? Just to double-check, which number did you use in there? And that number did you change it to after?
  9. My modifications works in the same way as it did in 3.4, to be completely sure of what exactly is going on I would have to take a look at the code of that widget though. And I have no access to it since it is a paid one. If you get permission from the widget author to provide me the code I can certainly take a look at it at least
  10. That's what moderators are for
  11. Yes. The bump plugin is simply to avoid useless replies with only "bump", or "up". It is commonly used in marketplace sections to bump own sell/buy topics for example. A reply to the topic will "bump" it as it usually does in any forum. Rather I'm confused by you asking this question, unless I misunderstood what you're asking?
  12. Oh, okay then. I'll try a few other ways locally to see if I can reproduce. If I can't find anything I'll try to guide you on how to debug through PMs.
  13. Could you PM me an admin & FTP account for your forum so that I can take a look? I can't duplicate locally. Or if you have an account on my site submit a support ticket in the client area. Either way works
  14. Looks like you already have a column with that name in your database. Did you have an older version of the bump up topic modification installed on 3.x? I remember adding a check for that but maybe I need to change how it works. Or did you simply update from 3.0.0 to 3.0.1?
  15. What he said, the plugin works by updating the last post value for the topic and thus bumping it up in forum view. It also of course marks it as unread for anyone else, that's because the last post time value after a "bump" is greater than the users last read stored time value.
  16. I actually coded this plugin on 4.0 but by the time I released it 4.1 was already out I will look into the activity stream update and see if it is something I can add
  17. This is the support topic for this file:
  18. What are you talking about? The file is free, I'm not even sure why you're talking about money. Anyway as the file description says the plugin hides the IP addresses in posts for all who can see them except for admins. In some countries there are (stupid imo) laws that force only a site administrator to be able to view such information.
  19. This is the support topic for this file:
  20. This is the support topic for this file:
  21. This is the support topic for this file:
  22. This is the support topic for this file:
  23. This is the support topic for this file:
  24. This is the support topic for this file:
  25. Parts of this entry may only apply to those who create hooks for IP.Board. Feel free to skip the sections that may not interest you. For IP.Board 3.2 I made several changes for both applications and hooks and now with this new major version I went ahead and made some more changes that I hope will simplify things for everyone. Applications Ordering Very often customers asked us for a simple way to reorder applications in the ACP, and subsequently in the front end, without having them split in 3 different categories (Root, IPS Addons and Third Party Addons) which for example prevented having the Blog link before the Forums one without having to manually modify the templates to add it. I am pleased to inform you that this is now possible without having to edit anything! This image shows the old layout with the split categories in IP.Board 3.2: While this one lets you see the new and updated layout in IP.Board 3.3: As you can see from the image above the System application (which is hidden for the front end) is always listed at the top but all the others can be re-ordered. Let's now take a look at the main navigation in the front end which properly displays the applications in our chosen order: Applications Status & Restrictions From the image above of the new layout you will have surely noticed that now the applications page has 2 tabs which list enabled and disabled applications, the disabled page looks exactly the same except for the first button which is a green plus to enable it opposed to the red cross in the enabled list. Note also that the uninstall button has been replaced with the enable/disable button and has been moved in the dropdown where the less used options are available, after all if you install an application on your community you want to keep it! Another change is the "Tab Restrictions" column which displays an icon to inform the admin that the front end tab may not show to some (or all) members depending on the chosen options: Application Details Unlike for hooks which already have a page to view all their details, applications had nothing and the list itself doesn't have any information about the application author, website and similar data. I have gone ahead and added a new view for that which lists most of the known information for the application: Hooks List For consistency with the new applications layout and the recent changes introduced in IP.Content the hooks listing now has two tabs to list enabled and disabled hooks while the old "Install a New Hook" tab is now replaced by a button which opens a modal popup to import the file: Hooks Settings Several hooks being released include new settings or whole new group settings but those settings are not always where you expect them. To help admins find those faster we have included a new link in the dropdown that takes you directly to the settings page once clicked. Since none of our default hooks add settings the example below is from one of the hooks I've released for free: Since hooks also support multiple groups or even individual settings in the image below as a test I have added a setting from the "Spam Prevention" group in IP.Board in the hook, as you can see both groups are now listed: Hooks Development Sometimes a developer might need to run code before allowing the admin to install or uninstall a specific hook, starting with IP.Board 3.3 this is possible adding the functions "pre_install" and "pre_uninstall" in the custom installation file. A simple example with the basic structure can be found below: <?php class myHookSetup { public function __construct( ipsRegistry $registry ) { // Your constructor code here } public function pre_install() { //This is run BEFORE the hook is installed on the board, nothing is added in the database or in the files yet } public function install() { //This is run AFTER the hook is installed on the board } public function pre_uninstall() { //This is run BEFORE the hook is unistalled from the board, nothing is changed/removed in the database or in the files yet } public function uninstall() { //This is run AFTER the hook is unistalled from the board } } Furthermore to make development of hooks easier the requirements page now provides an easy-to-use dropdown menu with the versions of the chosen application, there is no need anymore to search manually in the XML files the ID for the version you want to specify! Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.
×
×
  • Create New...