• Content count

  • Joined

  • Last visited

About TSP

  • Rank
    Frequent Contributor

IPS Marketplace

  • Resources Contributor
    Total file submissions: 8

Recent Profile Visitors

104,170 profile views
  1. Well personally I can see cases where a long cut-off time is "required". I would much rather have it be 3 days than 3 hours. Which is why I hope it would not be "impossible" to override whatever IPS may decide on. Maybe it could autofill if it's been less than 30 minutes or something and if it's been more than that it could show a banner. And if it's been more than 3 days it could be removed. But if it's moved to a banner, I feel it would be necessary to have a way to preview and discard the contents. (So you wouldn't have to click on it to have it be filled and then you would have to select all to remove if it wasn't what you expected or something)
  2. If it is replaced with a banner, then I really hope it will be prominent enough for users to notice, because personally I think the auto-save feature in is the best improvement in IPS 4 compared to earlier versions by far. The issues it presents, such as not being able to remove some content from the editor, is really separate problems that needs to be tackled on their own. Having a banner feels like you'll just be circumventing the real problems. Personally I feel an "empty content" button would be more of use, as that would circumvent other circumstances where the issues pops up. When you rewrite this, I hope you'll make it fairly easy to hook into to change the cutoff-time and whether it's a banner or autofilled ourself.
  3. Hi, So I realize there's been topics on this before, but I would just like to hear an update from you on this subject and present some issues I feel has been idling in the bug tracker for what I deem too long with no visible progress. You currently have 21 pages of bug reports in the "Active Reports" area, of which 17 pages are pending. The situation of you having 15+ pages of pending bug reports have, as far as I remember, been going back to early versions of IPS 4.0. Unfortunately it seems new issues trickle in as fast as you fix existing ones. I realize you're working as hard as you can, and that your resources are limited. But I feel you need to set apart some time specifically and systematically to go through bug reports at a much faster pace than you do in a normal situation for a certain period. I fear that you will or have already started work on IPS 4.2 before you do this, which will once again increase the amount of new issues once again when that's released. You've earlier emphasized that you feel going by the number of bug reports does not really tell anything about the state and stability of the software. I agree on this to a certain extent. The problem is that you often seem to give more attention to the newer reports and rarely give much attention to reports that "fell through the cracks" when they were new. These issues often go on a 6 month long idling time waiting around for someone to finally start working at issues from another angle. These issues still may have consequences that affect and annoy end users on a daily basis. The text editor is what I would consider the center piece of any community software and a lot of end users use and interact with it every day. It's what I currently receive a lot of complaints about. Here are for example two issues I feel should be given some added priority I've also noticed that reports that have been marked as "Rikki" or "Theme" seems to be the most frequent in reaching a state where they are untreated for a long period of time. Maybe Rikki should spend some more time in the Bug Tracker? I realize all staff are busy doing other things, but I feel you need to get a period with more systematically ensuring the number of bugs go down and start working on reports that have been around for a long time, especially the issues related to the editor.
  4. Do you have anything in the SQL error logs related to it? Sounds most likely that the connection haven't been saved for some reason. I would have a look at the SQL error log saved by IPS for the day the comment you have trouble checking was posted on. Send me a PM if you need me to log in to see further or you find me the error message.
  5. If you're a guest and given a link start a new topic somewhere you can't, for example: https://invisionpower.com/forums/forum/297-company-feedback/?do=add Then you receive an error message telling the page is not available to the account. Could this page receive the "log in/register" box that is at the bottom of topics when it's a guest seeing the error message? And possibly alter the error message a bit.
  6. Yes okay, but then you could potentially have even more stuff on the second screen. Chat windows or whatever.
  7. Why not simply have two browser windows open next to each other? You can read and do twice the amount in the same time! (Okay, not really, but you'll find some things faster)
  8. @Lindy: And here is what I did to merge two background tasks into one. I had then earlier mentioned this in a bug report which was closed. PLEASE NOTE: This was only done to account for the forums application, as that was all I had. IPS would need to review whether it would be possible to then remove the corresponding RebuildContentImages-tasks for their other apps too. Since this is in the same method though, it could use the same queue item data you would have to add based on my previous suggestion in my previous post here, to help determine inside the task php file whether it should use the new method or not. commit Author: Date: Sun Aug 30 17:00:56 2015 +0200 Merge two rebuild tasks diff --git a/www/applications/core/extensions/core/Queue/RebuildPosts.php b/www/applications/core/extensions/core/Queue/RebuildPosts.php index 8207c64..95def6a 100644 --- a/www/applications/core/extensions/core/Queue/RebuildPosts.php +++ b/www/applications/core/extensions/core/Queue/RebuildPosts.php @@ -191,6 +191,14 @@ class _RebuildPosts } } + /* HW_CUSTOM merged two tasks into one. Below code retrieved from RebuildContentImages.php */ + $rebuilt = \IPS\Text\Parser::rebuildAttachmentUrls( $item->$contentColumn ); + + if( $rebuilt ) + { + $item->$contentColumn = $rebuilt; + } + $item->save(); $last = $item->$idColumn; diff --git a/www/applications/forums/setup/upg_100028/upgrade.php b/www/applications/forums/setup/upg_100028/upgrade.php index e96d996..79c8617 100644 --- a/www/applications/forums/setup/upg_100028/upgrade.php +++ b/www/applications/forums/setup/upg_100028/upgrade.php @@ -33,9 +33,10 @@ class _Upgrade public function finish() { \IPS\core\Setup\Upgrade::repairFileUrls('forums'); - \IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic' ), 3, array( 'class' ) ); - \IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic\Post' ), 3, array( 'class' ) ); - \IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic\ArchivedPost' ), 3, array( 'class' ) ); + /* HW_CUSTOM merged two tasks into one. Commented out RebuildContentImages queue items */ + //\IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic' ), 3, array( 'class' ) ); + //\IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic\Post' ), 3, array( 'class' ) ); + //\IPS\Task::queue( 'core', 'RebuildContentImages', array( 'class' => 'IPS\forums\Topic\ArchivedPost' ), 3, array( 'class' ) ); \IPS\Task::queue( 'core', 'RebuildNonContentImages', array( 'extension' => 'forums_Forums' ), 3, array( 'extension' ) ); return TRUE;
  9. Not something I've experienced when doing this, but you obviously have to utilize and store the primary key you last rebuilt, like you do already. If you do that, I can't see any reason it should be slower than doing oldest to newest. As far as I remember, in your first versions you used offsets for the retrieval of the posts to rebuild, which obviously will be slow (and unreliable because you end up attempting to rebuild posts multiple times when new posts come in). So I suspect you're comparing apples and cars here. Here is the changes I did last time: You would probably need to add some code to account for cases where someone upgrades to this version with a new way to rebuild and they have an active process of rebuilding though. You could add some information to the queue item data after you've determined it based on previous versions and whether there is any queue taks for the rebuild, and then wrap the method it should use in an if/else block that checks the queue item data for whether it should use new or old method.
  10. How come? I've not noticed any problem with this method. And as far as I can judge from the code, the rebuild process is not dependent on earlier posts being rebuilt correctly. It just rebuilds the current post, the state of other posts doesn't matter.
  11. I have shared the changes to merge the two tasks I merged earlier and also to change the direction of the rebuild, but it wasn't picked up. As for the interval thing I did to have it be able to run the process from more than one php process feels more "hackish" and I would assume they would need to work on a more allround/client-friendly solution than what I did, so it's really nothing to share.
  12. Neowin took close to or over a month I believe with their 11 million posts. I did a pretty much standard rebuild for a 3 million posts board with all the tasks completed in about 3 days. I did however change the order the rebuilding was done in (so newest posts would be rebuilt first and thus decrease the likelihood of users noticing broken posts) and I decided to merge two tasks since it was a better use of time to have them work simultaneously in one task instead of two (because they both worked on the content column in the posts table and thus were both querying the posts table). For a 15 million posts board I decided this was not sufficient at all. So I decided to create a script that would allow me to run the rebuild with a 1 million interval on our 7 different production servers with each their starting interval, and also made changes to the standard queue task to not try to rebuild a post twice if it should happen to "catch up". Rebuild of posts was then completed in about a day.
  13. Guest caching has nothing to do with it.
  14. I'm getting annoyed at how post edits are being sent to the moderator log for cases where the member that posted the post is the member that edits it. Especially when they are not even a moderator. Could you reconsider this? For example only send a log entry for edited comments when someone edits a post that does not belong to their account. I really don't consider editing post content for a post you own to be a moderator action at least. That's what an edit log would be for. If your account do not "own" the post, then it's a moderator action.
  15. Right, they do. I was a bit quick here. The issue here is that the medium editor is applied to an area in desktop view (editing posts) where I expect the large one to turn up. This causes members to request a button to go to the full editor (like in 3.X) because they don't get all the same buttons as they get when writing the actual reply (Because IPS deems there is enough space for it). So I guess what I'm really requesting is to be able to decide the widths at which the different sizes of editor will show up. So I could lower the minimum breakpoint for the large editor. Alternatively I could put all the same buttons in the medium editor of course, but I'm not really sure that would be the best idea in the long run