AtariAge

I had a lot of my users question where it was.  It was one of the most used functions on my site.

I also share the in the aggravation with this latest version and how functions were hidden.  I don't see this "upgrade" as an upgrade, but rather a step back.  Like removing the ability to sort accounts needing approval by admin/user validation.  I get a lot of new registrations that require admin and email approval.  So now I have to go through all of the non email validations and ones who have validated their emails.  Its a mess.

I feel like my job has been made harder and is has made more work for me.  An upgrade shouldn't do that.

Just as the title say, please add "Go To Page" in the mobile version.

I have just tried getting to the last page in a topic with 20 + pages using my Android phone and it was agony. The previous and next buttons are handy but there seems to be no option to jump to a specific or last Pagination.

Can something be added please?

Thanks.

Quote

How many have you found to be missing messages since the change?

Quote

And is thus different from every other messaging system I've ever used, with the possible exception of Facebook.

If people are ignoring the count - so what, let them. You've removed information for the people that *don't* ignore it. If the notifications are going to act like that, why not shift them into the notifications feed? At least there it makes more sense that you are 'reading' the notification. But you can't do that because private messages are generally going to be more important and users will want them flagged up separately - and that's why there should be a persistent marker that they've not been read. A 'mark all read' option on the drop-down would make sense, though.

Direct quote from a user this morning: "The new pm numbers aren't working any more."

Forgoten Dynasty, on 19 June 2011 - 08:03 AM, said:

This post shows selfishness at its finest. It works for you so other's suggestions obviously have no merit. Duh.

We have upgraded the IPS Community to IP.Board 3.2.0!

This is the first step in the testing process for IP.Board 3.2.0's upcoming release. We will be testing the new version here for several weeks and working on fixing issues with the goal of our first public beta release being as stable as it can be.

Please look around and help us in testing by submitting reports to our bug tracker so we can all work together to create a stable release. Keep in mind that our applications - IP.Gallery, IP.Blog, IP.Calendar, IP.Chat, IP.Downloads, and IP.Content - have also all been updated to be compatible with IP.Board 3.2 so please also test those. Your help is greatly appreciated!

You may wish to review the What's New in IP.Board 3.2 topic for information on the exciting changes in IP.Board 3.2.


Downloading IP.Board 3.2.0

IP.Board 3.2.0 is not yet available for download.

We are using it here on our company forums both as a preview for feedback and to identify any possible issues before release. Before a final release we will be testing it here on our company forums for a few weeks and then posting betas for download for all active license holders and invite you to participate in the beta testing process when we reach that milestone. When the final, supported release is made available we will make an announcement here.

I notice in the recent blog http://community.inv...lowing-content/ for following content that there is mention of new settings to the user notifications.

I would like to see the ability for administrators to be able to set a default level of notifications for all users, who can then change them as required.

This setting should have the ability to either affect all current users or all new users, as required by the admin.

Ok think of it this way...

The STREAM of all incoming content is the tour-de-force by visually seeing this data for a site administrator and moderator presents a connection to the individuals on providing such content.

By crafting useful filters for such data provides further meaning to the context to the data being posted, and objectively provides tools for the duties that person is assigned.

When you say that showing topics without replies isn't going to make it - that sends my frustration factor thru the roof - that has been an on going request by many, on this site.
because that is how we ensure that people are posting in the proper forums and are being greeted and acclimated to our forums.

I don't wish to go to yet another link just to view or manually search for content with out replies. That defeats the purpose. Being in the stream of "viewing new content" filtering it down to threads
with out replies is an obvious filter option. If it is really that easy to add that to the list of filters - then do it, let us kick the tires in an actual test and we will tell you.

MOST of my power users  do not read the forums in a hierarchical manner, from the top down forum index. They look at the topics as they are presented and make a reply accordingly because
my forum is technical in nature and targeted to one specific industry or subject matter there is a lot of cross over of forum topics, or people are active in multiple forums.

We curate the threads by putting them in the proper forum for new users browsing the site they typically navigate the forum tree. For the duties of underpaid dedicated moderators and administrators
this basic feature is a necessity not a luxury.

This is another reason why we need to have a DATE driven pagination so that I can request ALL topics TODAY or YESTERDAY or LAST MONDAY and see a finite list of posts that have
NO REPLIES - as a moderator I can easily spot check the moderators have been doing their jobs by seeing if that list is nearly non existent.

I will state it again I don't wish to have another AREA or LINK to perform said task, but be included as a filter option with in the logic of VIEWING NEW CONTENT

This is another reason why I feel that the feature TITLE should be given more thought - from VIEW NEW CONTENT - to something like RECENT ACTIVITY or something that reflect the nature of the feature
being able to filter ALL CONTENT regardless of where it is posted. - I most likely will be modifying the language to reflect such connotation.

Please give this some further consideration....

Here's my situation. I have user names and display names enabled and I do not allow users to change their display name via the UCP. Instead I let them purchase the power to change their display name using points they've earned through posting via an app like ibeconomy. So now, if a user wants a different display name than their user name they'll have to wait until they've earned enough points?

Also, because of the display name history tool it will become easier for people to hack accounts now since you do not have to guess a person's user name. It'll be right there for you and now all you have to do is guess the password. I wish IPS would just let us choose to enable or disable things instead of getting rid of things all together because it makes things "simpler".

Matt, on 13 April 2011 - 07:10 AM, said:

Matt, could we have a "View topics without replies"?
This would be very helpfull.

Why is this not possible already? We can merge topics, close them, sticky them, delete them - but there is no way to choose topics from a result set when searching and move them to another category. There really should be a way to do this from a result set that contains topics.

It would really speed up the process of moving topics when new forums are created.

I'm afraid we're not going to make VNC show all content on the board.  Many users go there to find what is new (either posted since their last visit, or new to them because they haven't read it yet).  Showing every single topic ever and just highlighting the new ones makes it impossible to use this tool in an effective manner for the average user looking for new content.

Please inform us about this ticket, I'm in the same hell...

Performance Improvements

• Reduced several cache-load queries on the ACP index page
  
• Combined two permissions queries loaded on every ACP page into one
  
• Added some additional cache-loading calls to other ACP pages (manage applications, manage hooks, manage members)
  
• Added some caching for fetching the max version ID in the upgrade_history table, which reduces the number of queries on the ACP manage applications page by the number of applications installed
  
• Changed how modules are grabbed when IN_DEV is enabled for menu building (runs one query instead of one query per application)
  
• class_forums was getting loaded and initialized twice in the Manage Forums page - fixed so it's not reloaded a second time.  Also removed a shortcut for the class in the manage forums file to reduce small amount of overhead/memory.
  
• Removed a query for group data on Manage Forums page (group_cache is already loaded, so used that instead)
  
• Removed several deprecated functions, reducing the size of some classes and reducing their resulting overhead
  
• Edited language export routine (for IN_DEV mode) so that it only exports the data we absolutely need.  This reduces the size of our language XML files significantly, and also reduces memory overhead needed to process the language XML files.
  
• Index added on ibf_posts.post_parent to speed up certain update queries that previously required a full table scan
  
• A lot of unused code in the friend management files has been removed
  
• Avatar or profile photo cleanup tools in ACP were unnecessarily loading and instantiating upload class
  
• Removed outdated/non-functional coloring in admin logs
  
• Calendar has been rewritten, and much unused code has been removed.
  
• Caches used by calendar were not being properly loaded at runtime
  
• Changed most of the file_exists call in the code with is_file for a faster code execution
  
• The bbcode cache now uses the ‘bbcode_tag’ field as array key instead of an incremental integer, that allows a faster data access for single bbcode tags as there is no need to scan the whole array with a foreach.
  
• An unnecessary query has been removed from the forum index view (the query used to verify the name used for the friendly URL is correct)
  
• Removed unnecessary query from report center report view
  
• A cached used by report center was being queried separately instead of at page initiation
  
• Report center plugins are now cached for quicker runtime lookup without having to query the database
  
• Useless queries removed from report center
  
• Some queries that selected all rows and counted them (instead of running COUNT style queries) were changed to be better optimized
  
• ACP skin files previously extended the output class unnecessarily. This was removed, resulting in approximately 20KB or more memory savings in each ACP page.
  
• Report center plugins are now cached for quicker runtime lookup without having to query the database
  
• RSS import now is much faster on boards with lots of feeds setup in the ACP.
  
• overWrite header query / method_exists moved from every page load and value is cached in app_cache

Developer-Oriented Changes
Changes that may impact resource authors and skinners (including removed functions, database changes, new hooks, etc.)

• $this->DB->force_data_type has been removed.  Mod authors should now call $this->DB->setDataType( $column, $type ) instead.
  
• $this->DB->no_escape_fields has been hidden.  You should use the available $this->DB->preventAddSlashes( array( 'col' => 1 ) ); syntax instead.
  
• Login management custom configurations have moved to database handling.  conf.php (or conf.dist.php) files are no longer needed (though acp.php still is).
  
• search_results, sessions.location, and cache_store.cs_extra are all removed
  
• If you have a findIpAddress extension you can now add an array of additional columns to pull from your table as the fourth array member.  i.e. "'posts' => array( 'author_id', 'ip_address', 'post_date', array( 'pid' ) ),"
  
• IPB will now do a better job of cleaning up centralized application data during uninstall, so applications don't have to do it manually.  (http://community.inv...support-ticket/)
  
• The way hook data to-be-exported is stored has changed.  This should have minimal impact on developers as the upgrade routine will update it for developers.  This should make working with hooks between multiple developers easier, and make hooks import, export, install and uninstall in a much more consistent manner whether IN_DEV is on or not.
  
• Many skin system bugs have been resolved, and improvements implemented, making the skin system more flexible to developers using it outside of normal contexts, while allowing it to be more forgiving of various formatting possibilities (i.e. typehinting for function parameters and spacing around function parameter definitions).
  
• Central permission management now correctly can handle more than one permission type within a single application
  
• IPv6 is now supported.  You should ensure any database columns holding IP addresses are varchar(46) or larger.
  
• You should use the new ipsRegistry::getAppClass( $app ); call to load your app_class_(application).php class.  This ensures any library hooks execute as appropriate and consolidates duplicative code.
  
• You should use the new constants IPS_FILE_PERMISSION / IPS_FOLDER_PERMISSION for file and folder permission values.  i.e. instead of chmod( $file, 0777 ); use chmod( $file, IPS_FILE_PERMISSION ); instead.
  
• Calendar has been completely rewritten - the DB schema has changed, dates are stored as datetime parts in MySQL, etc.
  
• The ACP has a new interface implemented, some of the JS has changed, jQuery is now supported in the ACP
  
• Removed 4 data hooks in public_forums_forums_topics: topicViewTopicData, topicViewDisplayData, topicViewForumData, topicViewPostData. All 4 of them can be replaced with a simple skin overloader for the template "skin_topic > topicViewTemplate".
  
• Photos and avatars have been merged.
  
• Photos thumbs are now cropped at 100px and you can select which area to crop
  
• Twitter / Facebook photos are actually imported and re-sized where possible (needs fopen URL wrappers otherwise the thumb URL for the services is used)
  
• Some functionality for importing/exporting/rebuilding from and to XML files has been hidden unless IN_DEV mode is enabled
  
• Added a second parameter for the function “$this→cache→getCache( $CACHE_KEY, FALSE );” which allows to skip the loading from the database if the cache isn’t loaded already.
  
• A new option to define an application when creating an hook, if the application is filled the code checks if it is enabled and if not skips loading the hook file completely.
  class_forums::fetchTopicFolderIcon() has been changed to return an array of meta-data about the topic that can be used to generate the topic icon, although Rikki is changing how topic icons work in general anyways.
  pp_*thumb*_x is now pp_*small*_x
  
• The sessions API (admin/sources/classes/session/api.php) now supports a different cutoff time rather than the default one, additional joins, ‘where’ query bits, complete ‘where’ query part override.
  
• The function “IPSLib::unpackGroup()” now is “IPSMember::unpackGroup()”.
  
• ACP group_form.php plugins now support an optional third method: postSave(). This method accepts one parameter (the group ID), is only called if present, is called after the rest of the group data is saved, and should not return anything.
  
• Added a getCount() method to the like class to return just the number of followers
  
• The setting disable_reportpost has been removed. Our applications now check the report center permissions directly, instead.
  
• Hooks Improvements: http://community.inv...s-improvements/
  
• Applications Improvements: http://community.inv...s-improvements/
  
• A new extensions file per-app is supported: permissionsSync.php. Class name should be “(app)PermissionsSync” and supports a constructor (ipsRegistry reference passed) and one method with no arguments: updatePermissions(). This method can be used to rebuild application caches when the app permissions have been updated from the central permission manager.
  
• Deprecated function getBlogID() in the blog API has been removed, developers will need to use the more updated function fetchBlogIds()
  
• makeProfileLink, memberViewImages, makePassword, makeNameFormatted, canReceiveMobileNotifications have been moved to IPSMember
  
• unconvertSmilies has been moved to IPSText. The redirect method in the bbcode class has been removed.
  
• The “doneScreen” method in the admin output class has been entirely removed. Authors are encouraged to use the global_message/silentRedirectWithMessage() methodology instead.
  
• The “redirect” method in the admin output class now simply routes to silentRedirectWithMessage(), and is marked deprecated.
  
• The template “global_main_wrapper_no_furniture” has been removed from the admin skin.
  
• Function “rebuildSphinxConfig” has been moved from “IPSLib” to “admin_core_applications_applications”
  
• classCommunication.php was removed, and classFileManagement.php was extended to handle POST requests (encompassing the only functionality missing compared to classCommunication.php)
  
• Almost all private methods have been switched to protected to allow more robust hook capabilities
  
• New pagination potions to use a next/previous style pagination. Next/previous style pagination supports AJAX pagination.
  
• The column “ban_nocache” has been removed from the “banfilters” table.
  
• New adminOutput method setMessage() has been added. Allows to set the global_message, and allows to specify a “sticky” flag or not.
  
• ACP Settings are now in their own “settings” module and the templates have been moved as well in “cp_skin_settings”.
  
• menu.xml files for ACP modules now support specifying a language key, which can then be placed into “(app)_admin_menulang.php” as “menu__(language_key)” to support menu language abstraction in the ACP. This is optional for apps.

Can you change this data hook so that some more relevant data is exposed?  Namely, it would be nice if we had an array of real data about the active users.  All we actually get about the active users is an HTML link to their profile, we don't know their member group, and we'd have to do some trickeration on the HTML link to extract the member ID and/or name.

Here's a sample of what I get for data for this hook point on my localhost board:

Array
(
	[TOTAL] => 1
	[NAMES] => Array
		(
			[0] => <a href='http://localhost:8080/ipsdev/dev31/index.php?/user/1-michael/' title='Today, 01:01 AM'><span style='color:red;'>Michael</span></a>
		)

	[GUESTS] => 0
	[MEMBERS] => 1
	[ANON] => 0
	[text] => Our members have made a total of <b>25</b> posts<br />We have <b>2</b> registered members<br />The newest member is <b><a href='http://localhost:8080/ipsdev/dev31/index.php?/user/3-test/'>test</a></b>
	[posts] => 25
	[active] => 1
	[members] => 2
	[cut_off] => 15
	[info] => Array
		(
			[most_time] => 10 May 2010 - 02:32 PM
			[most_online] => 2
			[total_posts] => 25
			[mem_count] => 2
			[last_mem_seo] => test
			[last_mem_link] => http://localhost:8080/ipsdev/dev31/index.php?/user/3-test/
			[last_mem_name] => test
			[last_mem_id] => 3
		)

)

There's really not a whole lot of good data there that I can do anything with.  I am asking for this because one of the most common requests I get on my mods is to bring back the Group Name Indicator's ability to sort active users based on the group sorting for the mod.  Because I have no access to the group ID numbers of the active members, there's no way I could do this.  The only conceivable way I could achieve this right now is to extract the member IDs from these links and then query for their groups, that's dreadfully inefficient.  It would be nice if we just got raw data in this data hook that we could reorder, and then the actual construction of URLs was done either later in the source code or in the template.