BN_IT_Support

Hello.

I started with your distance calculation in Item.php:

      $selectClause .= ', ( 3959 * acos( cos( radians(' . $location['lat'] . ') ) * cos( radians( ' . static::$databasePrefix . 'latitude' . ' ) ) * cos( radians( ' . static::$databasePrefix . 'longitude' . ' ) - radians( ' . $location['lon'] . ' ) ) + sin( radians( ' . $location['lat'] . ' ) ) * sin( radians( ' . static::$databasePrefix . 'latitude' . ') ) ) ) AS distance';
 

I converted this to a PHP calculation (and I believe that I got the conversion correct!)

     $distance = (3959 * acos(cos(deg2rad($lat)) * cos(deg2rad($long)) * cos(deg2rad($event_long) - deg2rad($long)) + sin(deg2rad($lat)) * sin(deg2rad($event_lat))));
 

The problem is that this version of the calculation gave me 'NAN' (Not a Number) for the values that I tested.

After a quick Google for the algorithm I found the 'Haversine formula' and that seems to work OK.

     $distance = 3959 * acos(sin(deg2rad($lat))*sin(deg2rad($event_lat))+cos(deg2rad($lat))*cos(deg2rad($event_lat))*cos(deg2rad($event_long)-deg2rad($long)));
 

I conclude that your calculation in Item.php is incorrect.

John

Hi,

I don't have the answer, but...

I find it interesting that you would use your own editor on a Theme hook. I would agree that using your own editor on a Code hook is far more convenient than using adminCP editor, but for a Theme hook ??? Personally, I find the adminCP editor more convenient as it sorts out all the escapes (among other things). What motivates you to use your own editor?

Secondly, if this used to work before 4.7.16 and if you have NOT made any changes to your editor (either configuration or version update) then I can understand your point of view - that it should not have been broken.

That said, the Invision comments say "do not remove" and that implies "do not modify, either" and your editor has clearly modified the lines - what was '/*comment*/' is changed by your editor to '//comment' which is not the same thing.

John

Hello,

I believe that this is a more serious consequence of removing the 'Submit Details' button in 4.7.15. My previous topic about the 'Submit Details' button was because one of our plugins was triggering off the click on the button. Fair enough - that one is our problem and we have to find something else to trigger off. This is a different and more serious issue.

We have a number of custom applications and plugins so I disabled all of them on the test system and re-tested. The problem as described below is with all our custom or 3rd party apps and plugins disabled.

When users (members) submit images to the gallery we require them to provide both a title and a description for the image. That works fine on a laptop as details are automatically saved as you move from image to image and there is no longer any need for the 'Save Details' button.

The problem occurs on phones and other narrow screen devices. (The problem can be reproduced on a laptop by setting the window narrow like on a phone.)

• For example, on a phone add 4 images.
• Click the first image to add the details
• => the details popup covers the other images so it is impossible to select them
• => the details popup hides the submit button - although it is possible to rotate the screen/device to landscape mode and the submit button peeps out from behind the details popup.

In short, if you need to add titles, descriptions, etc. to several images then the images must be added and uploaded one at a time. Adding/uploading multiple images at a time results in inability to set details for more than one of them.

This is not a problem with the phone. It has been tested and is the same on iPhone, Android and laptop (when window is set narrow).

Regards,

John

29 minutes ago, Jim M said:

Items which were removed intentionally would not be added back in through a bug report. However, you're welcome to add this back in to your own theme if you so desire.

Jim,

Thanks for your quick reply.

My apologies - I thought that BNTEST was running with the 4.7.15 dev files -- I had upgraded BNTEST on 24th Jan and had downloaded the matching dev files on the same day. Evidently, I did not apply the dev files so the dev files must have been 4.7.14 which is why I did not spot the problem.

No - we'll not be adding the missing lines to our version of the theme. We have a strict policy of not changing any standard files because changed files quickly become a nightmare to maintain.

If the button is not needed in the standard software then we have no reason to add it back in. (Except we were forcing users to enter unique titles and descriptions by triggering off the 'Save Details' button so we'll have to find something else to trigger off 😉)

Thanks

John

Hello Support,

We upgraded the BNTEST site pretty much as soon as upgrades become available so it has been upgraded in stages including 4.7.12, 4.7.13, 4.7.14 an 4.7.15. We did not notice any problems because we run with IN_DEV all the time and the wrapper.phtml file (used in IN_DEV) still has the button!

We upgraded the BN site (our production site) on Sunday morning directly from 4.7.12 to 4.7.15 - being production we do not use IN_DEV and as the upgrade was performed in a single step we could not say which of versions 4.7.13, 4.7.14 or 4.7.15 introduced the bug - all that we can say with certainty is that both BN and BNTEST show the same bug (if INDEV is disabled) and that the upgrade path of BN and BNTEST was different and done at different times.

In simple terms, the standard Invision Theme gallery->front->submit->wrapper has 6 lines missing from close to the end. There are a number of <li> elements on the details form and then a {{foreach loop}} and then the button should exist on the form. Without the button it is possible to enter details for each image (including title and description) but it is not possible to save the details.

The missing lines are:

                <li class='ipsFieldRow ipsClearfix'>
                    <button type='button' class='ipsButton ipsButton_light ipsButton_fullWidth ipsButton_medium' data-role='saveDetails'>{lang="submit_go_back"}</button>
                    <p class='ipsType_light ipsType_medium ipsType_right ipsSpacer_top ipsSpacer_half ipsHide' data-role='savedMessage'>
                        <i class='fa fa-check'></i> {lang="image_info_saved"}
                    </p>
                </li>
 

I'd like to have this fixed ASAP 😉 I'd be quite happy to insert the lines into the database myself but I probably ought to follow some official procedure and if you have a patch for the issue then I should use that.

Thanks very much.

John

23 hours ago, Clover13 said:

A Pages DB would have...

As a general opinion on "Pages DB"...

They are not really "databases" in SQL terms -- but SQL "tables" in the Invision database.

When you are considering which sort of SQL table to use (within Invision) you have two choices:

1. "Pages DB" (as you have mentioned)
2. SQL tables as defined under the 'Database Schema' tab for an Application

Pages DB works well for:

• Where you only need a single table for all your data - for example, in the classic database design if you only need a "products" table then it will work well. If you actually need a "products" table and a "suppliers" table with cross references then it does not work so well - and in any case you would need two Pages DB (one for products and one for suppliers)
   
• Where the solution involves a human adding and editing records it works well - for example, where you have a human adding products (descriptions, part numbers, prices, etc.) to a product table. We probably use between 5 and 10 Pages DB for various unrelated things such as "news articles", "places to go" and so on.
   
• Using Pages DB automatically gives you various widgets such as "Database filters" which is good.
   
• I would strongly recommend that you use the standard display templates wherever possible. If you create your own display templates based on the standard display templates then that effectively bases your template on a snapshot of the standard template - you don't benefit from future improvements and bug fixes to the standard. We have some of our own templates from 6 or 8 years ago and regret not putting more effort into display formatting for individual fields. With some clever display formats you can combine fields to produce complex output (for example, latitude and longitude fields to display a map) and if you need to do conditional display of some fields dependent upon the contents of others then you can add a dummy field (with a non-blank default value so it triggers display) and you can write custom code to display the contents of several other fields according to the rules that you want to apply. Do the fancy stuff in a field display rather than a template wherever possible.
   
• When you write a scheduled task (for example) to update the data in a Pages DB there are a couple of (minor) extra steps that you need to take in order to write the data. Firstly, you need to know the classname that will be used to write to the correct table and this will be something like \IPS\cms|\Records23 where 23 is the database number. So, you have to look up the database number from your database key (I recommend against hard coding the 23 😉 ). Secondly, if you have fields for name, address, region, country, phone, etc. then the names in the table will be something like field_91, field_92, field_93, field_94, etc so you have to 'map' from the field key to the real field name in the database. Not difficult, but that's what you have to do.
   
• Pages DB will work OK where you have a scheduled task to update the data once per day (for example - it could obviously be much more frequently if you wanted). A scheduled task will work fine where nearly all the data items/records are accessed every day - but what about a scenario where only 5% of records are accessed each day? Doing a daily scheduled update of all records means that 95% of what you retrieve is not going to be used in the next 24 hours. I rather liked Nathan's suggestion of retrieving data on demand (i.e. every record has a lifetime field that you add so if you want the record but the lifetime has expired then you retrieve the data through the API). That would mean that you would not waste resources retrieving data that is not being used. Unfortunately, "retrieval on demand" would be extremely difficult or impossible to implement using Pages DB - unless you write your own very fancy templates and in that case you could do better to write an Application to do the entire job. Updating Pages DB from a scheduled job would work easily.

Application tables will work well for:

• You need several tables with relationships between them (e.g. products and suppliers)
   
• You need an application that does a lot of processing of records (rather than simple human entry of records as indicated previously)
   
• Access to records is more intuitive - field names are what you want to call them rather than being 'mapped'. Also, access to the correct table is very simple as you need to create a sub-class of \IPS\Patterns\ActiveRecord that will get you to the correct table plus a whole load more stuff.
   
• If you have hierarchical data (for example, categories and records) then you should consider using the Node/Model/Item/Content model although that gets a lot more complicated it does give you access to many of the features that you see time and again in Invision.
   
• You have complete control so retrieving data on demand is much more simple than it would be using Pages DB.

Regards,

John

On 2/9/2024 at 4:11 PM, Clover13 said:

I'm assuming the PHP is what's cached in a block not the data,

Would I be correct in deducing that you're referring to this (on a custom block)?

If so, no, it would be the data that would be cached so you would lose control of how and when it would be refreshed.

Certainly, you could use a custom block, but just make sure that you leave 'Cache this block' set to 'No' and then do your own caching.

The way that Nathan Explosion suggests is by far the best way...

Firstly, there is "how/when you retrieve the data":

• Scheduled polling would collect all the items even if some have not been updated. Daily polling would work OK if all items are updated every day but if only half the items are updated each day (for example) then you would be retrieving twice as many items as required.
• If you need the most up to date data for each item then you really need webhooks to notify you of changes - in the absence of webhooks you either set a very short scheduling interval or else use Nathan's solution with a short cache lifetime. You have now told us that you don't mind data which is not completely up to date (say - one day out of date) so webhooks are not essential.
• Nathan's solution where you load the cache on demand (i.e. only retrieve an item is it is not in your cache OR it is in the cache and already expired) - set the cache timeout to 12 hours or 24 hours or whatever depending how far out of date is OK.

If the rate limiting still causes problems then you might want to (need to) randomise the cache lifetime a bit. For example, with a fixed cache lifetime of 1 day if you start with an empty cache and if the users demand all data in a very short time then you might exceed the rate limit. (Not likely, but possible?) With a fixed cache timeout the same thing will happen the next day as all items will expire at the same time. Randomise the cache time with +-60 minutes and lookups will be distributed over time very quickly.

Secondly, there is "how/where to cache the data":

• If you only need a single lookup key per item (e.g. a name OR an id) then Nathan's suggestion of using the data store is the best way to go. (I've used it where I only need one key per item and it works very well.)
• If you need multiple lookup keys per item (e.g. name AND id so you sometimes retrieve from cache by name and sometimes by id) then the data store does not have that flexibility so you would probably need an SQL table with multiple keys - unless you double your storage usage by saving each item under both the name key and the id key. (I have multiple tables with multiple keys which is why I think that way 😉 )

John

5 hours ago, Clover13 said:

Use Zapier OR code a script (scheduled under cron) to GET from the third party API and POST the data to a Pages DB

If you're going to go down this path then I would be inclined to use a 'task' within your Invision Application - that way you can use the API to pull data directly into your application rather than pull the data with Zapier or a separate cron script and then post it into your application.

An important question - how far out of date can you allow the data to be? If the data must be up to date within 5 minutes then your script will have to run every 5 minutes and if your application does not display all the data frequently then you may well generate more activity pulling data on a schedule than you would pulling it on demand.

Is there a way (in the API) to detect data that has been updated - so that you don't have to pull all the data periodically?

The most useful thing would probably be if the API includes webhooks that will fire and notify your application if a data item/record is created and when one is updated -- i.e. you then use your webhook to pull data that has changed and don't bother to pull data that has not changed.

If there are no webhooks in the API as an alternative will the API let you 'list all records that have been updated in last 10 minutes' (for example) - that way you would use the list of recent updates to select which records to pull (i.e. only those that have been updated since last pull).

Finally, I would be inclined to store the data in your own database (i.e. table defined by your application). Effectively, the database table acts as your cache and if your cache is only updated on data change (webhook or whatever) then it would probably be far more efficient than trying to use the Invision cache (which will have its own timeouts that are not necessarily in sync with updates to the data...)

John

Hello,

Version 4.7.15

compileFullEmail attempts to fold long headers by using the wordwrap function - but this does not work correctly as whitespace gets 'swallowed' and the extension line does not start with white space. The rule for Long Headers (those that exceed 998 bytes) is that they should be split so that the next part starts with white space -- i.e. crlf ma#y be inserted before the whitespace and NOT as a replacement for the whitespace. "unfolding" only works correctly if the follow on lines start with white space -- i.e. "Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP."

Our particular failure scenario was when using our application to send to approximately 100 recipients as the $to field then exceeded 1,000 bytes and the To: header was split incorrectly. This then messed up the mail server processing resulting in failures to deliver. Quite probably different mail servers mess up in different ways - in our particular case the mail server put the extension line in the Subject: field and decided that there was no From: header.

Regards,

John

On 12/27/2023 at 3:59 PM, Jim M said:

please ensure that your server is able to connect to our license server: remoteservices.invisionpower.com

/usr/bin/curl  https://remoteservices.invisionpower.com

(from my server -- no browser available) returns immediately with no error.

Using Firefox (from my laptop) returns

<html><head></head><body></body></html>

Ditto - having the same symptoms right now...

Attempting to upgrade from 4.7.12 to 4.7.14

John

4 minutes ago, Marc Stridgen said:

The only thing I would include, is to run the requirement checker before upgrading to the latest release

Marc,

Thanks for all replies. Will run the checker as advised.

John

32 minutes ago, Marc Stridgen said:

your only option at present is to upgrade to the latest release of the platform

Marc,

Thanks. As Invision 4.6.12.1 does not work with PHP 8.1 I am presuming that AdminCP would not work on that version so I cannot do an automatic upgrade. Correct?

Does that mean that I have to do a "manual upgrade" following this outline:

1. Maintenance mode
2. Backup files + DB
3. Switch to PHP 8.1 (current Invision installation no longer works at this point)
4. Manual upgrade to latest Invision
5. Normal mode

Or, in full, to include FileRun in the sequence:

1. Maintenance mode (both FileRun and Invision)
2. Backups (both FileRun and Invision)
3. Upgrade FileRun to latest (this includes the step to switch to PHP 8.1)
4. Manual upgrade Invision to latest version
5. Normal mode (both FileRun and Invision)

Thanks.

John

Hello,

Self hosted.

Normally I would keep our website relatively up to date but in this case we got stuck at 4.6.12.1 because one of our other critical bits of software (FileRun) did not support PHP8/PHP8.1.

I would like to be able to upgrade Invision and FileRun separately so that I don't end up with failed upgrades in both components at the same time. I am now in the situation where:

• My current Invision (4.6.12.1) does not work on PHP8.1 (I tried it and the Calendar died)
• The latest Invision (4.7.11.1) does not work on PHP7.4 (running on my system)
• My current FileRun does not work on PHP8.1
• The latest FileRun does not work on PHP7.4

My thought is that upgrading Invision to 4.7.3 would give me an intermediate point which could run either PHP7.4 or PHP8.1 and would allow me to switch the PHP version back and forth while I sort out the FileRun issues. (Once FileRun has been upgraded and is operating OK then I would upgrade Invision to the latest, anyway...)

If there is a better way to address this topic then I'd be interested to hear about it.

If this is the best way then please may I have Invision 4.7.3 so that I may upgrade to that intermediate point?

Thanks very much.

John

Hello Support...

I followed the topic at: 

In addition to the main problem, the guide does not properly describe the naming and creation requirements:

1. Layout name must start with "layout_" and cannot just be any old name that you choose - as in the document.
2. You must not just copy all the settings to the "_preview" template as the base template has a single variable ($users) whereas the "_preview" template does not have any variables.

The main problem occurs when using admin to create or edit a staff directory to specify the layout. The admin utility is forced to "Theme zero (id=0)" and you cannot follow the instructions in the document to edit this theme. The result is that the admin utility cannot find your custom layouts so they never get offered when creating or editing a staff directory.

That's it.

If you access the database directly and insert your custom layout name into the relevant records in core_leaders_groups then when users view the staff directory it works OK and your custom layout is picked up. (If you then use admin to edit the staff directory then it loses the custom group from that particular directory because admin cannot see it.)

Having wasted a lot of time following the document and trying to get it to work, I now believe that a better method for our particular scenario is to hook into the 'layout_blocks' template and add our additional fields via the hook. In our scenario that has the added benefit that when we disable/delete our application (or plugin) it will also leave the directory definitions in a clean state that will continue to work (without the additional information).

Regards,

John

Hello Adriano,

I thought that "Contact Us" always used to work correctly (past 5 years, at least) but it now seems to be completely broken and departments appear to not work. I'm not sure exactly when the problem started but we recently upgraded Invision to 4.6.5.1 and Contact Us to 1.3.4 and that appears to have broken things.

I have uninstalled Contact Us from our test system (bntest.org.uk) and reinstalled it from the marketplace but the problem seems to be just the same.

When I use Contact Us it does not matter which department I select (we have 5 departments) as they all behave the same. The email is ONLY sent to Settings::i()->email_out plus the submitter if the submitter requests a copy. The email does NOT get sent to any of the members of the department.

Our departments are set up with no groups selected, only one additional email for each group. Examination of the PHP indicates that groups and additional email addresses should be handled the same way.

In Contact\Contact.php it seems to do the send of the email. Before the send of the email it is built by a call to buildEmail().

The function buildEmail seems to accumulate all members of the department group and of the additional emails under the variable $staff and then assign it to $this->cc. The function also accumulates Settings::i()->email_out and optionally the user email under $email and assigns this to $this->to.

The email is then sent to $this->to and the $this->cc appears to be ignored.

Well, I don't want the email sent to Settings::i()->email_out and I only want it sent to the list that you accumulated under $staff plus optionally the user. I thought that that was the way that it used to behave before 1.3.4.

Thanks very much.

John

In June and July this year we successfully used the "Elections System" for elections of our Directors and Executive Committee. Only members can vote. All members are eligible to vote for some positions whereas other positions are regional so only those members residing within that region are eligible to vote. This was so easy to set up within the Elections System!

Before deciding to use the Elections System we looked at alternative products but could not find any that integrated with our membership database - let alone in such a straightforward way. Also, we approached 3rd party organisations to get quotes for the cost of running our elections. Quotes were returned upwards of £300 for one-off elections and we would have to pay the same for next year's elections and so on. (I believe the quotes were under-estimates because they did not fully understand the complexity.) Was this a cost effective solution? Go work it out for yourself!

Driven by Covid-19 (and a desire to move into the 21st Century) we will also be doing online voting for our AGM Motions - but they will use the "polling" function built into the forums.

Back to the Elections System and our experience. We used version 1.0.4 because that was the version that we tested before going live. I note that 1.0.9 has been released and it enhances a few things - which is really great!

1. Previously you had to create an "Organisation" and add all nominees to an organisation - which was a pointless extra step for us as we only have one organisation (and the IPS group structure is the way to manage regional eligibility to vote). Organisations are now optional which saves that extra step. Thanks!
    
2. Nominees may now attach their "manifesto" ("election address") to their avatar in the ballot so that potential voters can click on the manifestos before deciding who to vote for. Thanks!

There are still a few quirks with scope for improvement, but I certainly recommend this product. Quirks:

1. For a nominee who is not in an organisation their avatar on the ballot shows a failed image load at the lower right (they have no organisation image to load at this point)
    
2. When you click on the "manifesto" link for a nominee the manifesto pops up fine (which is good) but the title shows "json--1--"
    
3. It would be good if there was an option to hide the "running total of votes" during the election. Furthermore, at the end of the election only the election officials (perhaps one or more selected groups) should be able to see the results. Certainly, the election officials should see the results before the voters so that any disputes can be resolved. (We have our own plugin to hide the running totals -- so that's an easy thing to do.)

Other than that - great work!

Thanks

John

Hello,

There is a minor problem when running SuperGrid templates 3.1.0 and SuperHelp templates 1.4.0 on Invision 4.4.7. The problem arises because in one of the releases Invision changed the default namespace so that references to the 'count' function no longer default to the PHP function (in the root namespace '\') but default to the relevant IPS namespace. The solution is to force all references to the PHP count function to be the root namespace by using '\count' instead of 'count'.

1. When using IN_DEV mode any access to SuperGrid or SuperHelp pages results in an exception and the message that for performance reasons references to 'count' should be replaced with references to '\count'. This means that I cannot test any of the SuperGrid or SuperHelp pages on my test system except by switching in and out of IN_DEV mode.
    
2. When running in 'normal' mode the software appears to run correctly. But, presumably there is a performance hit. That is, in normal mode references to 'count' are still not going directly to the PHP function but are being caught by an Invision function which then calls the PHP function by forcing a reference to the root namespace.

Thanks and regards,

John

Adriano,

Thanks -- seems to fix the problem. Nice!

John

43 minutes ago, Martin A. said:

Thanks for letting me know. I've uploaded a repacked version, as the first one was compressed in the TAR format (but named .zip),

Martin,

Thanks very much for the quick fix!

John

Hi Martin,

The 3.5.2 Membermap Zip will not open on Windows 10.

Thanks very much...

Hello - 

Version 1.2.0 fails (on IPS 4.3.5) - I've had to back out to 1.1.17 which still seems to work OK.

The problem is somewhat strange - it seems to work once after flushing the cache and then fails repeatedly. Flush the cache and it works once and then goes back to failing repeatedly. The implication is that the cache hold something stale (either that, or the process of creating the data to go in the cache also sets up something as a side effect so that un-cached first time works).

(When I say "flush the cache" I mean going into adminCP "Support" option and then selecting "Something isn't working properly".)

We have the same problem on both 'test' and 'live' systems.

System Log shows:

ParseError: syntax error, unexpected ';' (0)
#0 /var/www/vhosts/bn.org.uk/httpdocs/system/Theme/Theme.php(4291): IPS\_Theme::runProcessFunction('\tfunction email...', 'email__cjcontac...')
#1 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(780): IPS\_Theme::makeProcessFunction('New Contact Us:...', 'email__cjcontac...', '$member, $name,...')
#2 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(328): IPS\_Email::devProcessTemplate('email__cjcontac...', 'New Contact Us:...', Array)
#3 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Outgoing/Php.php(41): IPS\_Email->compileSubject(Object(IPS\Member))
#4 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(518): IPS\Email\Outgoing\_PHP->_send(Array, Array, Array, NULL, NULL, Array)
#5 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(108): IPS\_Email->send(Array)
#6 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(85): IPS\cjcontact\_Contact->sendEmail(Array)
#7 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(68): IPS\cjcontact\_Contact->sendRecord(Array)
#8 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/modules/front/contact/contactus.php(36): IPS\cjcontact\_Contact->form()
#9 /var/www/vhosts/bn.org.uk/httpdocs/system/Dispatcher/Controller.php(96): IPS\cjcontact\modules\front\contact\_contactus->manage()
#10 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/modules/front/contact/contactus.php(25): IPS\Dispatcher\_Controller->execute()
#11 /var/www/vhosts/bn.org.uk/httpdocs/system/Dispatcher/Dispatcher.php(146): IPS\cjcontact\modules\front\contact\_contactus->execute()
#12 /var/www/vhosts/bn.org.uk/httpdocs/index.php(13): IPS\_Dispatcher->run()
#13 {main}

Thanks very much.

John

14 hours ago, Genestoy said:

Will this plugin work also on a 4.1.9 board?

I think so.

6 hours ago, Genestoy said:

Were there some instructions that I missed? I didn't see any.

Immediately below the message format selector where it says 'Select one of the standard message formats or use 'custom' to select your own formatting options below.'

5 hours ago, Genestoy said:

Installed on 4.2.3 and colors won't change, either one background or text and the left right center does not work, nor does the setting for displaying it on a certain page? Any ideas?

Thanks

Are you sure you’ve selected the custom formatting option?