Foxtrek_64

Hello, I received an application tar file from a developer. When attempting to use the manual upload function with the tar file, I can select the tar file and click the Install Button. This loads for a couple of minutes, then my server returns a 504 Gateway Timeout Error. Installing applications directly from the marketplace seems to work as expected (or did while the Marketplace was open), but the manual upload fails. I'm not sure if this is because the actual upload fails or some other issue. No errors are reported by either my site host nor in the logs in the ACP. Any ideas what may be contributing to this issue?

I did find an option to "Disable contact link hook" in the Forms settings. This changed both contact links to go to `/contact`, but there's still the question of why Contact Us is listed twice and the cookies page is missing entirely. I assume this has to do with the fact that Forms 1.4.6 is not compatible with a couple of the changes in this latest version of Invision.

Running Forms 1.4.6 on Invision 4.7.13. My footer links are exhibiting some strange issues. Contact Us is listed twice, and both go to the /forms page. Disabling the Forms plugin changes the first Contact Us link to go to /contact and the second Contact Us link is replaced with the Cookies link. There does not appear to be any sort of configuration in the Forms Settings in the ACP that would affect this. Any ideas what might be happening here?

I have a field called Title which is shown under the user's role in posts and on the user's profile in place of their role (thanks to theme template edits, if set. This field allows staff and donors to decorate their profile with a custom, short title. Because edit access should not be allowed to every user, I have the "Member can edit value?" field set to false in the permissions section of the field. However, this has an unfortunate side effect. Moderators and donors are now unable to change their own field, or for moderators, that of others. This field is not visible when editing profiles in the moderator cp. If someone wishes to use this perk, an admin must be contacted and the field must be edited from the admin cp. I'm not quite sure how we want to tackle this issue, but allowing moderators to edit these fields for other users would be a good first step. A fully-featured solution would see edit permissions be configurable.

As an unintended but possibly useful side effect of this feature change, it would be possible to specify any link after sign out. This could be used for redirecting users to a particular forum thread or even a different website (e.g., when users sign out of forum.example.com they are redirected to www.example.com). While there is somewhat of a concern of this being used to redirect users to a malicious site, this would require a compromised administrator or administrator account, which would fall under Microsoft's ten laws of security.

Hello, I wanted to suggest this so it's officially on your radar. Currently, we support Single SignOn by allowing for alternative (and perhaps multiple) logon providers to be specified. This allows us to log in via a Microsoft or other account. However, Single SignOff is not supported at this time. This leads to unexpected behavior where a user will attempt to sign off, perhaps to sign on to an alt (a common step for my staff who have separate, elevated admin accounts). Clicking the sign off button initiates a logout from the forum account, but when the site reloads it will automatically sign the user back in. As a temporary work-around, I have suggested my administrators use Private/Incognito mode in their browser when logging in with their elevated account as closing the browser forces sign out by deleting login cookies. That said, myself and my users would expect that the logoff button actually signs them out and leaves them signed out. Most OAuth providers have a sign off link that will sign the user out and redirect them to a configured site after signing out. For example, this link could look like `https://auth.example.com/signout?redirect=https://forum.example.com`. Others have this redirect link configured on their end. To cover most OAuth providers, a field should be provided that accepts a logout redirect, possibly with a replacement available for the canonical homepage of the forum. The log off button the forum would then simply perform all of its normal checks, then instead of redirecting to the homepage of the forum it would redirect to the provided URL. This will not cover all cases, but I imagine it would be a simple enough addition to cover situations where the OAuth provider offers the feature. If desired, a disclaimer could be placed on the field describing situations where the feature will and will not work. Later implementations may see other scenarios, such as making a POST request to a sign off endpoint but without actually redirecting the user to that page, but I would consider this to be outside of the scope of this suggestion.

Not sure if the support board is the right place to post requests but I would like to see more functional options for after a form is submitted. Send a DM (done) Post a new thread (done) Post a new reply to a thread (done) Set Submitter's Primary Role On Submit On Approve (useful for things like staff applications) Add Secondary Role to Submitter On Submit On Approve (Stretch) Replace reply form in specific thread/board with custom form. Or more generically, mark a form as Reviewable, which will do two things: Add option to approve or deny to the thread options (on original post). Bonus points if you can get a banner under the original post, perhaps occupying the ad slot that already exists there. For groups allowed to Review the item and allowed to see the Moderator Control Panel, add an action item to the MCP with options to approve or deny. Allow admins to define actions to take upon approve/deny. This could be things like sending a reply to the thread, modifying user primary/secondary roles, etc.. For the UI side of things, I imagine this could be presented as a list (much like the forms and their questions are today), and it just executes any described tasks in order. Thanks for the fantastic plugin!

I want to allow members to add a profile field which allows them to link to a specific post in a specific board. Is there a better way to do this besides using a URL type and regex that filters to `https://www.example.com/forums/forum`? Some other fields allow specifying a particular database record for instance, but profile fields only seem to include the basic types.

I want to create a user profile field that displays under the user's profile picture on posts, which is fairly straight forward with a template modification. However, there only seems to be two permission options: whether or not the member can set the value. I want to take a more nuanced approach - I want this field, which is just a free text field, to be displayed only if the user is a member of certain groups. Otherwise, it should only be configurable by an administrator, just as all profile fields can be modified directly in the ACP. Is there a way to do this out of the box or will I need to look at plugin development for this?

Hi all, just a general question. I couldn't find this in the documentation so I thought I'd ask here. Under System -> General Configuration, there is an option to specify your "main site." When toggled on, it accepts a name and a url. After enabling this option and providing the requested information, I took a cursory glance to the front-end of my website and found nothing to be visibly different. What does this setting actually control? Is it just setting the field for API purposes or does this option have an effect somewhere?

You say you want proof of purchase in PDF form, but I've poked around on the FontAwesome website and I'm unsure what document you want us to provide. Could you provide some additional info on what you're looking for? Or alternatively, given that FontAwesome now uses kits, simply have us provide the url to the kit, that being https://kit.fontawesome.com/KitId.js. This should be sufficient to allow us to use theoretically any past, current, or future version of FA and allow you to wash your hands of any licensing issues.

Hi all, an update on this issue. I heard back from the site host. They recommended that I place an `exit()` call just above 941 of Marketplace.php, thus aborting the install and letting me inspect the downloaded tarball. Doing so, I was able to test extraction both into the temporary folder and into the /home/public/applications/form directory from the command line. Both were successful. Finding this to be successful, I then went back in and removed my exit() modification and commented out line 942, which is the call to the _checkChmod method. Invision was able to successfully download and extract the tarball, but was unable to open Application.php for writing, which is to be expected. This tells me the exception is likely being thrown when @chmod() is called in the _checkChmod function due to invalid permissions. I have reverted the changes for now, but I believe I have discovered two potential solutions for this issue, both of which will require developer intervention: Wordpress is able to handle this via a command-line tool. I'm not too sure what that looks like or how it works, but the web host reports that Wordpress sites are able to successfully install plugins from their marketplace through this method. It may be worth giving a look. Change to a Wizard-based updater for plugins which will pause to allow administrators to manually chgrp/chmod files as appropriate.

After doing some digging, it seems I've identified the issue. The article @ThunderBlue linked was partially correct in that it gave me a place to look, but my analysis lead me to a different location. The stacktrace for the error refers to line 941 of Marketplace.php, but I believe the issue is actually on 942. Line 941 extracts the downloaded tarball to the applications directory. Line 942 calls a function called _checkChmod, which according to documentation for the function, "recursively check[s] and adjust[s] CHMOD permissions after uploading an application." The user account Apache is using, named `web`, which represents web users, does not have chmod permissions. This is causing an exception to be thrown, which is accurately described by the error message but not by the stack trace (though that's PHP's problem, not Invision's). I am pursuing two avenues to resolve this issue: I am working with my hosting provider to determine a viable work-around. They seem to have granular chmod permissions set up anyways, so allowing the `web` user to use chmod in the applications directory might be viable, but we are looking at alternatives. I have reached out to the plugin developer about getting the install files so I can install the update manually, though I am still waiting on a response. I would like to recommend, and I can place this somewhere else separately if need be, that the step that attempts to perform the chmod changes is modified. If it fails, instead of simply throwing an exception, it should prompt the admin to modify permissions themselves. Then they can click continue when they've finished or they can click cancel which safely aborts just like is done now.

When attempting to update a plugin via the marketplace, it fails and I get the following in the system log: Cannot extract "Application.php" to "/home/public/applications/form/Application.php", setting file permissions failed Is this caused by the apache user account attempting to run chmod or a similar command on Application.php? Permissions on the existing Application.php file are 775, so it shouldn't be an issue with writing the actual file. Is this caused by the apache user attempting to run chmod on the Application.php file and then throwing an exception because it doesn't have permissions or is there another issue here?

Thanks for the catch there, Daniel! I'll disable the plugin then upgrade again. That plugin has been giving me issues lately because despite having an upgrade itself, upgrading consistently fails. Haven't been able to resolve that one yet. Also, I made a change to the ips4.php document. I'm no php developer, but I was able to resolve the errors. What seems to be happening is `-1` doesn't match the regex string and the original code makes the assumption that the `memory_limit` will always be in the form of #g, #m, or #k. In an official change I'd probably check the length of $match before trying to grab the second entry. But this works as a quick proof of concept. <?php $_memoryLimit = @ini_get('memory_limit'); $memoryLimit = $_memoryLimit; if ($memoryLimit != '-1') { preg_match( "#^(\d+)(\w+)$#", strtolower($memoryLimit), $match ); if( $match[2] == 'g' ) { $memoryLimit = intval( $memoryLimit ) * 1024 * 1024 * 1024; } else if ( $match[2] == 'm' ) { $memoryLimit = intval( $memoryLimit ) * 1024 * 1024; } else if ( $match[2] == 'k' ) { $memoryLimit = intval( $memoryLimit ) * 1024; } else { $memoryLimit = intval( $memoryLimit ); } } ?> <?php if ( $memoryLimit == '-1' || $memoryLimit >= 128 * 1024 * 1024 ): ?> <li class="success"><?php echo $_memoryLimit; ?> memory limit.</li> <?php else: $success = FALSE; ?> <li class="fail">Your PHP memory limit is too low. It needs to be set to 128M or more. You should contact your hosting provider or system administrator to ask for this to be changed.</li> <?php endif; ?>

Hello, I'm attempting to upgrade from v4.6.9 to 4.7.5. I was waiting for my host to provide newer versions of PHP and finally gave up and migrated to a new host. Everything's working on the new host with my board disabled, but I wanted to upgrade before I opened up my board again. When running the upgrade, I get the following exception: Fatal error: Declaration of IPS\form\_Log::getItemsWithPermission($where = [], $order = null, $limit = 10, $permissionKey = 'read', $includeHiddenItems = IPS\Content\Hideable::FILTER_AUTOMATIC, $queryFlags = 0, ?IPS\Member $member = null, $joinContainer = false, $joinComments = false, $joinReviews = false, $countOnly = false, $joins = null, $skipPermission = false, $joinTags = true, $joinAuthor = true, $joinLastCommenter = true, $showMovedLinks = false) must be compatible with IPS\Content\_Item::getItemsWithPermission($where = [], $order = null, $limit = 10, $permissionKey = 'read', $includeHiddenItems = IPS\Content\Hideable::FILTER_AUTOMATIC, $queryFlags = 0, ?IPS\Member $member = null, $joinContainer = false, $joinComments = false, $joinReviews = false, $countOnly = false, $joins = null, $skipPermission = false, $joinTags = true, $joinAuthor = true, $joinLastCommenter = true, $showMovedLinks = false, $location = null) in /home/public/applications/form/sources/Log/Log.php on line 730 I made sure I had followed the guide for changing hosting providers and everything appears to be fine there. I also downloaded a newer version of the ips4.php file and I pass all requirements (php memory is -1 which is less than 128M, which is why I think that error is shown. Not sure about the undefined array errors). What are my next troubleshooting steps for resolving the upgrade exception?

I'm getting this error when updating from 1.4.0 to 1.4.1 using the marketplace tab in my acp: Extraction from phar "/tmp/IPSMPWgrC4w.tar" failed: Cannot extract "Application.php" to "/var/www/html/applications/form/Application.php", setting file permissions failed I contacted Invision support and they said to contact the plugin developer. This is what permissions look like: [root@lfp-rrweb form]# ls -lah total 12K drwxrwxrwx. 11 root rrweb 160 Sep 1 2020 . drwxrwxrwx. 7 root rrweb 89 Sep 1 2020 .. -rwxrwxrwx. 1 root rrweb 4.6K May 18 08:21 Application.php drwxrwxrwx. 2 root rrweb 4.0K Sep 1 2020 data drwxrwxrwx. 4 root rrweb 49 Sep 1 2020 extensions drwxrwxrwx. 2 root rrweb 85 Sep 1 2020 hooks drwxrwxrwx. 2 root rrweb 24 Sep 1 2020 interface drwxrwxrwx. 4 root rrweb 50 Sep 1 2020 modules drwxrwxrwx. 11 root rrweb 183 Sep 1 2020 setup drwxrwxrwx. 5 root rrweb 61 Sep 1 2020 sources drwxrwxrwx. 2 root rrweb 24 Sep 1 2020 tasks drwxrwxrwx. 2 root rrweb 26 Sep 1 2020 widgets I would think I wouldn't run into any permissions issues like this, but apparently so. Any suggestions on where I should look or what I should change to fix this issue?

I ran into this issue earlier today. In my case, I had logged in to the marketplace with the forum admin account, then attempted to do so with my personal account. Once I disconnected my invisioncommunity account from the forum admin account, I was able to connect it to my personal account without issue. Not sure if this case applies to you but I thought it'd be worth sharing.

Good catch, @Nathan Explosion. Setting the truncate type to hide and then getting the full content resolved the issue. Thanks!

I have tried using both 'hide' and 'none' as values. After saving and refreshing, I can see the new value when inspecting the html, however there does not seem to be a change in behavior.

I have a custom page which displays an announcement database I have built (separate from the built-in announcements system). This database syncs with an announcements board where users may post comments. I am using the Category Articles template to display my announcements but I am not happy with how the truncation is working. By default, the template renders the data like so: <section class='ipsType_normal ipsType_richText ipsType_break ipsSpacer_bottom' data-ipsTruncate data-ipsTruncate-size='7 lines' data-ipsTruncate-type='remove'> {$record->truncated()|raw} </section> I would theorize that the data-ipsTruncate-type is what determines how the truncation is handled, though I am unsure what other values are valid here. The current truncation effect seems to be doing two things: Shorten to seven lines maximum - this I am fine with. Remove all formatting - this breaks content such as lists, and I would like to avoid this. I have looked through the database settings but I was unable to find anything that affected this by default. Did I miss something in the options that would resolve this? If not, how can I change this to behave the way I would like it to. Is there any developer documentation available for review so that I can see the what these properties control and what their values are?

As an amendment to my issue, this seems to only affect the Checkbox Set type of question. Changing this to a Select Box with the Multiple Values option turned on causes the field toggle system to work as expected, however in my mind the select box is less intuitive for nontechnical users.

Hoping this one can be answered by one of the devs out there who play with CSS on a regular. I have built a custom contact page that uses the forum css classes to produce sections with links. One such section, where I've been having an issue, looks like this: https://cdn.discordapp.com/attachments/468748717684686868/771564822621323306/unknown.png Specifically, I have two questions. Firstly, is there a CSS class that would solve the alignment issue with the information section at the top, and one that'll add in a dividing line between that and the first item? Secondly, when compared with the title on the actual forum, the title entry is too small. The HTML I'm using, for reference, looks like this, content omitted: <ol class="ipsList_reset cForumList"> ... <li class="cForumRow ipsBox ipsSpacer_bottom ipsResponsive_pull"> <h2 class="ipsType_sectionTitle ipsType_reset cForumTitle">Copyright Claims (DMCA)</h2> <div class="ipsDataItem_meta ipsType_richText"> <h3>What is the DMCA?</h3> <p>The Digital Millennium Copyright Act (DMCA) creates a standardized process for copyright holders to ask LuzFaltex to take down infringing content. You can find more information about the DMCA at the <a href="http://www.copyright.gov/" target="_blank">U.S. Copyright Office's official website</a>. For more information on how LuzFaltex handles DMCA request, please read our <a href="#">DMCA takedown policy.</a></p> <p>As with all legal matters, it is always best to consult with a professional about your specific questions or situation. We strongly enourage you to do so before taking any action that may impact your rights. Our guides aren't legal advice and shouldn't be taken as such.</p> </div> <ol class="ipsDatList ipsDataList_large ipsDataList_zebra ipsList_reset"> <li class="ipsDataItem ipsDataItem_responsivePhoto ipsClearFix"> <div class="ipsDataItem_icon ipsDataItem_category"> <span class="ipsItemStatus ipsItemStatus_large cForumIcon_normal"> <i class="fa fa-gavel"></i> </span> </div> <div class="ipsDataItem_main"> <h4 class="ipsDataItem_title ipsType_large ipsType_break"> <a href="...">Submit a DMCA takedown notice</a> </h4> <div class="ipsDataItem_meta ipsType_richText">If someone else is using your copyrighted content in an unauthorized manner on the RavenRock RP website or its affiliated sites, click here to submit a DMCA takedown notice and request that the infringing content be changed or removed. Before you begin, please read LuzFaltex's <a href="...">guide to submitting a takedown notice</a>.</div> </div> </li> <li class="ipsDataItem ipsDataItem_responsivePhoto ipsClearFix">...</li> </ol> </li> ... </ol> In the standard forum, the title of the forum entry is styled with cForumList ipsDataItem_title. Here the setup is identical as far as layout, but that combination doesn't seem to be detected by the CSS engine. Is this some sort of typo that I'm just not seeing or is there another issue going on here?

@Michael.J Any ideas on this?

I was able to get it with modifying the template. I'm not unfamiliar with template modifications, but I was trying to figure out if I could do it with the built-in copyright text system.