Jump to content

Matt

Management
  • Posts

    70,143
  • Joined

  • Last visited

  • Days Won

    649

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Invision Community 5 Bug Tracker

Forums

Events

Store

Gallery

Everything posted by Matt

  1. Nice idea!
  2. We're going to drop "Blogs" from the main Invision Community navigation bar to make space for Events. We're just waiting for a few other things first.
  3. Personally, I think it needs a few more links like so:
  4. Thanks, I've lowered the threshold a bit and will contact AWS about this image to see why it was flagged.
  5. Last visit is not the same as last activity. When a user's session is active, we update the last_activity column. When the user's session times out, or when they come back for the first time, we update last_visit time with the last_activity time. It does look a bit odd when the sessions are so close, so perhaps we can do something being mindful of anonymous logins.
  6. Welcome to our September developer's update! I can say with some confidence that both the Invision Community team and our marketplace developers have had a busy September as we prepare for PHP8. Thank you for your patience with this necessary step. As I've mentioned elsewhere, PHP8 is a pretty big jump and is much more strict about many things, and now throws fatal errors when before it would have been a harmless notice. PHP7 is now end of life, and security updates will no longer be available from November. Preparing for PHP8 I've talked about this on the forums a lot over the last few weeks, but I'll summarise the timeline here so you can prepare your plugins and apps to be PHP8-ready. September release (4.7.2): The PHP8 scanner will disable any plugins and applications that would cause issues with PHP8, but Invision Community owners can re-enable them if they choose to do so. October release (4.7.3): A warning shows in the AdminCP if Invision Community is installed with PHP7. As of October, the PHP8 scanner will disable plugins, but they can be re-enabled. November release (4.7.4): The PHP8 scanner will disable plugins and applications found not to be PHP8-ready. They cannot be re-enabled via the AdminCP. The only way to re-enable them is to upload a new version. Code changes to be aware of October hasn't been the biggest of releases, but it does come with the new Events front-end for Calendar, and this changed the parameter signature for getItemsWithPermission(), which is probably the most overloaded method we have. The new parameter signature is as follows: public static function getItemsWithPermission( $where=array(), $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 ) Note, $location has now been added to the list. If you overload getItemsWithPermission then you will need to update any hooks with his new parameter, or it will be flagged via the PHP8 scanner. The reason for this addition is to allow an easier way to get items via a latitude and longitude lookup. If you manage this elsewhere, you might find using getItemsWithPermission a much simpler way. @Daniel F has also been working on improving the GraphQL API, and the GraphQL library has been updated to 14.11.6. We'll cover the upcoming GraphQL changes in a future blog. Deprecations Invision Community is a mature product, and some features and code that we added in the past no longer make sense, work correctly or are no longer appropriate for a modern platform running on well-maintained servers. You can see the upcoming deprecations in this topic. I suspect the biggest change will be removing the option to allow Display Names to form part of the authentication credentials when logging in, which is coming out in November. The other to watch for is the removal of the sockets fallback for when curl is not installed on the server or using a version older than 7.36. It's worth noting that curl 7.36 was released in March 2014 and now has hundreds of CVEs (known vulnerabilities) however, our techs still come across the odd server still using an older version. We will likely run AdminCP notifications to warn those affected of the upcoming socket fallback deprecation nearer the time, as it has no version attached. Just be mindful of this in your own apps if you use sockets directly for anything. You may also note that we've started adding deprecations to the release notes. As a reminder, we do not approve Marketplace submissions that restore functionality we've removed. That's it for September! Hopefully, it won't take too long to run through your apps and plugins. As always, comment here, or reach out via the forums if you need anything clarifying. Happy developing!
  7. Hi all, I'm just letting you know that the September Development blog is out now and covers our PHP8 ready schedule and an important change to a very much used and overloaded function. Thanks!
  8. Matt

    4.7.3

    This is our October maintenance release. Key changes include: Updates to the Calendar App (now Events app) to showcase online and offline events
  9. We only show the bolder button and banner to non-team to avoid adding more visual noise to regularly used interfaces for moderators. Per-forum options aren't a bad idea although I'm always initially cautious about overloading ACP interfaces with switches and toggles and adding more code burden. If it comes up a lot, we'll definitely consider it. I think what we're leaning towards is asking for the purpose of the topic at the point of the user starting by checking "I have a question" or similar which will then encourage the interfaces changes.
  10. I would definitely ask that those who feel that their modifications are now compliant, but are still getting flagged to let us know so we can further fine-tune the scanner if required. They can reach us in the marketplace devs slack channel we have, via the developer connection forum or via PM. I'll speak to Esther this week to see what's going on.
  11. We are planning an October release. 🙂
  12. @My Sharona I would hope that mod authors are working on getting their products working with PHP8 already. It's worth checking the marketplace (4.7.2 compatibility), or reaching out to ask them directly if they have completed this step yet. @DamonT We'll try to get the November release out the first week of November to avoid putting pressure on our support and dev teams over Thanksgiving. As @Marc Stridgen has pointed out, you are not forced to upgrade so if you need a few more weeks that is fine.
  13. As you may have noticed, we've been doing a lot of work to prepare Invision Community to use PHP8 as the minimum version. If you are an Invision Community Cloud client, then you do not need to worry about any of this, and can happily click out of this topic. For those who host Invision Community on their own servers, then please read on. PHP7 is now end of life and from November, PHP will no longer offer security updates. PHP8 is a major update which brings many changes including how errors are either logged and means that what was a harmless notice or log entry is now a fatal error which Invision Community cannot capture. We have introduced the application and plugin scanner to ensure that your site is not "bricked" (unrecoverable from a fatal error) when you upgrade to PHP8 although you currently have the option to re-enable any disabled applications or plugins. From the November 2022 release, we will require PHP8.0 as the minimum version. If you are currently using PHP7 then you must contact your host and plan your PHP8 upgrade to ensure compatibility with Invision Community from November onwards. We are rolling out dismissible AdminCP banners to those who are currently on PHP7. If you are unsure what version of PHP your server is running, simply log into your Admin CP then navigate to System > Get Support and check out the PHP version block. The November release of Invision Community will also mean that you are no longer able to re-enable plugins the application scanner disables. We continue to work on this tool to refine its error checking and logging verbosity. If you have any questions, please let me know below.
  14. I completely understand. Our main focus now is to make our app simpler. Simplicity doesn't mean we lose power, expandability or configurability but it does mean that we can simplify workflow processes. For example, CSS editing; as we allowed core CSS files to be edited, we needed a conflicts and merge system to detect changes and offer the admin a chance to automatically merge these changes in. This is a lot of complex code that we can remove. We also presented multiple ways in the AdminCP to edit CSS which leads to a weaker UI and more confusion. It also makes our documentation more complex and longer as we explain both methods. By choosing simplicity and a single way to add custom CSS, we greatly simplify the code, the workflow and our documentation and make the software easier to use.
  15. We really do. We've had to be firm about some things and make decisions to ensure we are still a relevant platform in the 2020s but we truly do care about our customers. We want our customers to have a great experience with the software, during upgrades and way into the future. Your community's success is our success.
  16. There's a lot of confusion here, so I'll do my best to address it all. Why have you removed CSS editing? First off, we have NOT removed the ability to edit and add CSS to your themes. When we released Invision Community 4.0 way back in 2012, we added a "custom.css" file and asked everyone to add their custom CSS to this file. This means that when we make changes to the core CSS, you do not have to merge changes, or re-apply edits. Your custom CSS is untouched. This is exactly what CSS is designed to do. The core CSS may contain something like this. body { font-size:14px; font-family: Helvetica; margin: 10px color: black; } So, what do you do if you want to change the colour to red? In the past you could edit this core CSS file directly and make it like so: body { font-size:14px; font-family: Helvetica; margin: 10px color: red; /* Changed color here from black */ } This would work fine BUT if we changed our core CSS to change the font-size to 16 like so: body { font-size:16px; font-family: Helvetica; margin: 10px color: black; } This will now overwrite your changes, which means you'll need to re-edit it back to: body { font-size:16px; font-family: Helvetica; margin: 10px color: red; } This does work, but means you are constantly having to compare your changes to ours. Fortunately, CSS (cascading style sheets) is designed to allow new CSS files to overwrite rules that we set, and that is why we have a custom.css file ready for you to make your upgrade-proof edits. So, if you wanted to make the body colour red, instead of editing our code and maintaining changes, you simply add this to custom.css body { color: red; } CSS knows to combine OUR rules with YOUR rules. It's exactly what CSS was designed to do. The computed result (how the browser sees it) of this is exactly the same: body { font-size:14px; /* from our core css */ font-family: Helvetica; /* from our core css */ margin: 10px /* from our core css */ color: red; /* from custom.css */ } This is clearly a much better way of changing the CSS rules. You can keep all your custom code in one place and you no longer have to maintain copy and paste edits to core CSS. In short, CSS editing STILL VERY MUCH EXISTS! Why this change? To be frank, it's 2022 and there's no valid reason at all to be editing core CSS when CSS itself was designed to cascade and make your lives easier. We should have locked out editing of core CSS a long time ago. As the web moves on, we have to move on too. Serving CSS from a single CDN will improve the page speed of your site as it will come from a cached no-cookie domain. No modern application out there will allow you to edit core CSS, there just is not the need. I realise that for a very small number of people this means changing how you work, but this is how you should have been working since 4.0 was released a decade ago. If you actually use custom.css I promise once you have completed the initial population of this file, your life will be made so much easier! This is industry standard If you look at other apps, they allow you to add custom rules that cascade over the core CSS files. Like Squarespace, and Wordpress which states: "You can use the CSS editor to customize the appearance of your WordPress.com site. It works by allowing you to add your own CSS styles to override the default styles of your theme."
  17. You absolutely can still do that. You can still add as much custom CSS as you want. The only thing we have changed is to stop the bad practise of editing core CSS files. CSS cascades. That means we can set the colour of a selector to green, and you can add a cascading rule to change it to red. It’s how it’s always been.
  18. If you do see anything odd, let me know.
  19. I'm definitely open to ideas and suggestions to help drive up beta release adoption and feedback. In addition to peer reviews, we had six beta releases.
  20. Yeah, you can manually patch it and 4.7.2 will complain about edited files, but it's fine to overwrite them.
  21. It was fixed in 4.7.2, but it's a simple edit:
  22. That is a PHP 8.1 bug. It has been fixed in 4.7.2.
  23. Show me your code and the base code. I did see we used \IPS\node\Controller instead of an uppercase “Node”. Is that what you’re seeing?
  24. Hopefully you'll see far fewer plugins and apps being disabled from now on.
×
×
  • Create New...