teraßyte

IPS has approved the new 4.0.0 version. 👍

Someone from IPS needs to approve the new version (4.0.0) before it shows up for download. In case you don't want to wait the file is already available on my site: https://community.invisionbyte.net/files/file/274-tb-bump-up-topics/

What kind of extra features exactly? 👀

Just noticed this while I was updating the file description after I submitted the new version for this file: The file has 7 screenshots uploaded but editing the file I get 14 screenshots listed instead (I uploaded 7 new images updated with the 4.6 theme). It should show only the ones for the currently approved version.

Hello guys! Here's a quick quote of what I've already mentioned in other support topics: For those interested this is the changelog for the new 4.0.0 version:

Btw, I ended up investigating this because I'm updating my Bump Up Topics plugin and the new version wasn't running the upgrade script.

First here a list of the plugins attached to this topic with a list of what they do in each upgrade step: 1.0.0 => Adds 1 setting (testing_upgrade_setting). The install script creates 1 table (aaaa_install) and updates the setting value to 3. 1.0.1 => The upgrade script updates the setting value to 4. 1.0.2 => The upgrade script creates 1 table (aaaa_upgrade). 2.0.0 => The upgrade scripts for versions 1.0.1 and 1.02 are removed (empty XML entries). The upgrade script for version 2.0.0 creates 1 table (aaaa_upgrade) and updates the setting value to 5. 2.0.1 => The upgrade scripts for versions 1.0.1 and 1.02 are restored (no empty XML entries). The upgrade script for version 2.0.0 only updates the setting value to 5 and the one for version 2.0.1 does nothing. ====== Now, let's start with a list of tests to be done with these plugins: === TEST #1 (all OK): 1) Install version 1.0.0: The table aaaa_install is created. The setting testing_upgrade_setting is updated to value 3. 2) Upgrade the plugin to version 1.0.1: The setting testing_upgrade_setting is updated to value 4. 3) Upgrade the plugin to version 1.0.2: The table aaaa_upgrade is created. All working as expected in this test. === TEST #2 (install BUG): 1) Now uninstall the plugin and install version 1.0.1 directly: The table aaaa_install is created. The setting testing_upgrade_setting is WRONGLY updated to value 4. The code to update the value to 4 is present ONLY in the ips_plugins_setup_upg_10001 class which shouldn't run on install. This problem is caused by the code below in applications/core/modules/admin/applications/plugins.php (lines 851-870): if ( $class AND $xml->getAttribute('long') ) { if ( $xml->getAttribute('long') == 10000 AND $data['isNew'] ) { /* Installing, so use install file which is bundled with <version long="10000"> */ $key = 'plugin_' . $plugin->id . '_setup_install_class'; \IPS\Data\Store::i()->$key = $class; $data['storeKeys'][] = $key; $data['setUpClasses']['install'] = 'install'; } else if ( $data['currentVersionId'] < $xml->getAttribute('long') ) { $key = 'plugin_' . $plugin->id . '_setup_' . $xml->getAttribute('long') . '_class'; \IPS\Data\Store::i()->$key = $class; $data['storeKeys'][] = $key; $data['setUpClasses'][ $xml->getAttribute('long') ] = $xml->getAttribute('long'); } } The elseif code in this case should be executed only if it's not a new installation: else if ( !$data['isNew'] AND $data['currentVersionId'] < $xml->getAttribute('long') ) At least I don't expect "upgrade scripts" to run when I'm doing a fresh install since any changes would be already included in the "install script". A similar issue happens also if you install 1.0.2 directly as a new plugin. But in that case also the table aaaa_upgrade included in the 1.0.2 upgrade step is created in addition to the setting being updated. === TEST #3 (all OK): 1) Continuing from the second test, upgrade the plugin from version 1.0.1 to version 1.0.2 directly: The table aaaa_upgrade is created. All working as expected in this test. === TEST #4 (upgrade BUG): 1) Uninstall the plugin and install version 1.0.0 again: The table aaaa_install is created. The setting testing_upgrade_setting is updated to value 3. 2) Upgrade the plugin directly to version 2.0.0 (skipping version 1.0.1 and 1.0.2): The table aaaa_upgrade is NOT created. The setting testing_upgrade_setting is NOT updated to value 5. The upgrade in this case doesn't work because the 1.0.1 and 1.0.2 upgrade files were deleted before exporting the plugin. The upgrade code is completely skipping running the upgrade scripts if even one is missing. The problem here is that if we can't skip including empty upgrade scripts (I usually delete them) we need to have some kind of warning when downloading/exporting that it's gonna cause issues. === TEST #5 (install BUG which actually makes it work): 1) Uninstall the plugin and install version 2.0.0 directly: The table aaaa_install is created. The setting testing_upgrade_setting is updated to value 3. This is actually the expected result for a new install but the upgrade scripts in this case aren't running simply because 2 of them are missing and thus the code is skipping them all. === TEST #6 (install BUG same as TEST #2): 1) Uninstall the plugin and install version 2.0.1 directly: The table aaaa_install is created but also the table aaaa_upgrade is WRONGLY created. The setting testing_upgrade_setting is WRONGLY updated to value 5 instead of remaning set to 3 from the install script. This is again an install bug which executes all the upgrade scripts on install. But unlike version 2.0.0 (with its missing upgrade scripts) version 2.0.1 has them all restored which makes the code run them. ====== Sorry for the really long post but the whole thing was driving me crazy so I wanted to be sure to cover every scenario. To sum up this bug report there's 2 problems: Installing a plugin from scratch should run ONLY the install script. Either fix the code not running any upgrade script if some are deleted/missing before exporting (empty XML entries), or add some kind of IN_DEV warning when downloading/exporing the plugins to make us aware that some required(?) files are missing. Testing Upgrades 1.0.0.xml Testing Upgrades 1.0.1.xml Testing Upgrades 1.0.2.xml Testing Upgrades 2.0.0.xml Testing Upgrades 2.0.1.xml

Thanks for the confirmation. 🙂

This is the support topic for this plugin:

@Subdreamer New 2.0.3 version has been approved. 👍

This is the support topic for this plugin:

The code below is from the template applications/core/dev/html/global/global/poll.phtml (lines 60-90): {{if $poll->canVote() || !member.member_id || $poll->canClose() || ( ( $poll->poll_close_date instanceof \IPS\DateTime ) and !$poll->poll_closed ) || ( ( $poll->poll_close_date instanceof \IPS\DateTime ) and $poll->poll_closed )}} <hr class='ipsHr'> {{if $poll->poll_closed}} <p class="ipsType_reset ipsType_medium ipsType_unbold ipsMargin_vertical:half"> <i class='fa fa-lock'></i> {lang="poll_closed_for_votes"} </p> {{endif}} <ul class='ipsToolList ipsToolList_horizontal ipsClearfix cPollButtons'> {{if $poll->canVote()}} <li class='ipsPos_left ipsResponsive_noFloat ipsToolList_primaryAction'> <a href="{$url->setQueryString( '_poll', 'form' )}" title='{lang="show_vote_options"}' class='ipsButton ipsButton_small ipsButton_light ipsButton_fullWidth' data-action='viewResults'><i class='fa fa-caret-left'></i> {lang="show_vote_options"}</a> </li> {{endif}} {{if !member.member_id}} <li class='ipsPos_left ipsResponsive_noFloat'> {lang="poll_guest" sprintf="\IPS\Http\Url::internal( 'app=core&module=system&controller=login', 'front', 'login' ), \IPS\Http\Url::internal( 'app=core&module=system&controller=register', 'front', 'register' )"} </li> {{endif}} {{if $poll->canClose()}} {{if ! $poll->poll_closed}} <li class='ipsPos_right ipsResponsive_noFloat'><a class='ipsButton ipsButton_link ipsButton_small ipsButton_fullWidth' href='{$url->setQueryString( array( 'do' => 'pollStatus', 'value' => 0 ) )->csrf()}'><i class="fa fa-lock"></i> {lang="poll_close"}</a></li> {{else}} <li class='ipsPos_right ipsResponsive_noFloat'><a class='ipsButton ipsButton_link ipsButton_small ipsButton_fullWidth' href='{$url->setQueryString( array( 'do' => 'pollStatus', 'value' => 1 ) )->csrf()}'><i class="fa fa-unlock"></i> {lang="poll_open"}</a></li> {{endif}} {{endif}} {{if ( $poll->poll_close_date instanceof \IPS\DateTime ) and !$poll->poll_closed}} <li class='ipsPos_right cPollCloseDate ipsResponsive_noFloat'><span class='ipsType_light ipsType_medium'>{lang="poll_auto_closes_on" sprintf="$poll->poll_close_date->localeDate(), $poll->poll_close_date->localeTime( FALSE )"}</span></li> {{elseif ( $poll->poll_close_date instanceof \IPS\DateTime ) and $poll->poll_closed}} <li class='ipsPos_right cPollCloseDate ipsResponsive_noFloat'><span class='ipsType_light ipsType_medium'>{lang="poll_auto_closed_on" sprintf="$poll->poll_close_date->localeDate(), $poll->poll_close_date->localeTime( FALSE )"}</span></li> {{endif}} {{endif}} The <ul> element with the ipsToolList class is missing the closing </ul> at the bottom right before the last {{endif}}.

This is the support topic for this application:

Btw, the conf_default column for the setting in my DB is set to the unlimited value * (asterisk). I made a new similar field (this one defaults to an empty string though) and the setting works just fine like that (well, it simply falls back to the default empty string value).

Here's the steps to reproduce the issue: 1) Create a simple form with the following code: $form = new \IPS\Helpers\Form; $form->add( new \IPS\Helpers\Form\CheckboxSet( 'my_chekboxset_field', ( \IPS\Settings::i()->my_chekboxset_field ? ( \IPS\Settings::i()->my_chekboxset_field == '*' ? '*' : explode( ',', \IPS\Settings::i()->my_chekboxset_field ) ) : '' ), FALSE, array( 'options' => \IPS\Member\Group::groups(), 'multiple' => TRUE, 'parse' => 'normal', 'unlimited' => '*', 'unlimitedLang' => 'all_groups', 'impliedUnlimited' => FALSE ) ) ); 2) Now disable the setting (or Customize and deselect all options) and save the form; this will save the setting as an empty string in the database. 3) When the form is reloaded the setting is fully enabled (all Customize options selected). At this point I would actually expect the YesNo setting to be off (all Customize options deselected) but the code instead falls back to the unlimited value if the setting is an empty string (it should do that only if the field has the same * value). By removing the unlimited option the form field acts as expected with no options selected on page load. The only way I found to make it work is to specifically set the value to NULL when the setting (or the options array for customize) is empty which makes it NOT fall back on the unlimited value: if ( empty($values['my_chekboxset_field']) ) { $values['my_chekboxset_field'] = NULL; } === There are also a couple of other related issues I noticed: The same issue with the unlimited value happens also when using a Select helper form The unlimitedLang option for the CheckboxSet form helper doesn't work because the template applications/core/dev/html/global/forms/checkboxset.phtml (line 49) is hardcoded to use all instead of the passed $unlimitedLang template value: <a class="ipsCursor_pointer" data-action="checkboxsetAll">{lang="all"}</a> / <a class="ipsCursor_pointer" data-action="checkboxsetNone">{lang="none"}</a>

Version 2.0.3 submitted. Just waiting for IPS to approve it now. 😉

I ended up installing PHP 8 locally to test things directly. I've confirmed both the issue and the fix. I'll release a new version soon. 👍

The problem here is that actually the addHeader() function doesn't have a 4th parameter to pass the ID. The ID is hardcoded to use the form id together with the header string and the name you provide as the 1st parameter instead: public function addHeader( $lang, $after=NULL, $tab=NULL ) { /* Place the input into the correct position */ $this->_insert( \IPS\Theme::i()->getTemplate( 'forms', 'core' )->header( $lang, "{$this->id}_header_{$lang}" ), NULL, $tab, $after ); } So yeah, not exactly a bug. It would be nice it IPS allows to pass a custom ID as 4th parameter just like the other form helpers though.

@Subdreamer Actually hold on about that PM. I just had a quick talk with @Adriano Faria and he gave me a clue of what the issue possibly is. I'll send you a PM myself with an updated version of the plugin for you to test. I'll send it either tomorrow or in the weekend. 👍

That's the issue most likely then. The environment I use doesn't have a PHP 8 package available yet so I need to setup a different one from scratch for it. For now it's probably faster if I just investigate the error on your server. Can you please send me a temporary FTP account as well in the PM?

@Subdreamer What PHP version are you using? If I remember right someone else mentioned plugins throwing error with PHP 8 but I've only tested them up to PHP 7.x so far. In case can you send me a PM with an ACP account for your site? Not sure what's going on exactly but I can have a look around.

The link can be found in the top menu: Help > PRODUCT ASSISTANCE > Providers => https://invisioncommunity.com/third-party/providers/ I'm on that list too. 😉

Guess I spoke too soon, a few more searches on all suite files with the 3 strings below return more wrong addToStack() calls: 79 results , NULL, array( 'sprintf' 17 results , NULL, [ 'sprintf' 8 results , NULL, array( 'htmlsprintf' Using a regex search for NULL on the same line after addToStack might return even more results. Haven't tried that though, just a thought.

Noticed it completely by chance while I was looking at the email templates for something else. Run a quick search in the folder \applications\core\dev\email for this string: $email->language->addToStack( 'guest_name_shown', NULL, array( It returns 10 results. While NULL as the second parameter for the $vle variable still works just fine the value is supposed to be FALSE (boolean). Most likely a copy/paste error when support for the guest_name_shown language string was added in the email templates since it's only those addToStack() calls that use NULL. 😋

The email template \applications\core\dev\email\unsubscribeStream.txt contains a broken link: <ips:template parameters="$streamId, $streamTitle, $key, $member, $email" /> {$email->language->addToStack("unsubscribe_blurb_stream", FALSE, array( 'sprintf' => array( $streamTitle )))} {$email->language->addToStack("unsubscribe_blurb", FALSE)} {$email->language->addToStack( 'unsubscribe', FALSE )}: {url="app=core&module=discover&controller=streams&do=unsubscribeFromEmail&id={$streamId}&gkey={$key} The unsubscribe link on the last line is missing a double quote, the base parameter and the closing parenthesis: {url="app=core&module=discover&controller=streams&do=unsubscribeFromEmail&id={$streamId}&gkey={$key}" base="front"}