z929669

@Makoto 
Hi, any news for my last question or this will be the end of this app?

Hi @Makoto How we will manage to renew your app now?

+1 to this – what's the status of Radical Tags as the Marketplace closes? 

Keep in mind that a manual edit of your database is not recommended or supported (Any issues resulting from this change will not be supported.) so while that may work for you, it is not something we suggest.

The application is already compatible with the current IPS build as of 1.11.2. You can proceed with the upgrade and update the RT application to the latest release.

This has been resolved in the 4.7.4 release that has just gone out 

Sorry, we would not provide a way to resolve this via the database but we can help you resolve any issues that are impacting you from doing this via the ACP.
We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 
We look forward to further assisting you. 
 

You will want to setup your Achievement rules, ranks, etc... then use the rebuild button in ACP -> Members -> Achievements -> Settings. 

I will mention it then. The IPS CSS has so many redundancies it isn't even funny. This change didn't impact me, since I do use custom.css, but in maintaining that implementation since IPB 2.x, it's been clear that the CSS is very hacky with many different people having worked on it in silos over the years. This is demonstrated by the frequent use of !important in the CSS definitions to override the otherwise ridiculously convoluted selectors that even the devs don't want to touch.
Now with talk of improving the CSS implementation, it's almost a certainty that my customizations will be broken in the future ... these past few 'upgrades' have come with many major downsides (e.g., the Topic Feed uselessness ... don't even get me started).
Such is the way of SAAS software: optimize the software for the devs and the non-technical customers whilst alienating the technical/power customers ... dumbing down the world.

I will mention it then. The IPS CSS has so many redundancies it isn't even funny. This change didn't impact me, since I do use custom.css, but in maintaining that implementation since IPB 2.x, it's been clear that the CSS is very hacky with many different people having worked on it in silos over the years. This is demonstrated by the frequent use of !important in the CSS definitions to override the otherwise ridiculously convoluted selectors that even the devs don't want to touch.
Now with talk of improving the CSS implementation, it's almost a certainty that my customizations will be broken in the future ... these past few 'upgrades' have come with many major downsides (e.g., the Topic Feed uselessness ... don't even get me started).
Such is the way of SAAS software: optimize the software for the devs and the non-technical customers whilst alienating the technical/power customers ... dumbing down the world.

I also focus on good content. Content does not fall under the purview of IPB's software engineers, which is who this thread is addressed to. This thread is focused on IPB taking away the ability to easily modify the CSS files, which in turn makes it very difficult for those who do actually care about site speed to be able to do anything to address it.

This comparison is incorrect, that's why I wrote it.
Below is an objective comparison from a test now from my friend's site @sadams101
1. IPS default theme - without ad blocks included
- there are no reported web vitals indicators in the test because it does not pass the test successfully.
Site load test

 
2. Test with a used theme - after numerous changes in the CSS loading method, without changing the content CSS rules, All advertising blocks included - more than 6-7 objects in a page.

And of course - web vitals test

Do you think it makes sense?
Each site has its own specificity in displaying its content - (how much value content has - that's another topic). That's why every site uses css rules of different importance. In order to speed up the loading of all resources, it is essential to speed up the loading of the used rules, and postpone the unused css rules...
This is impossible only using custom.css. This is also impossible using designer mode.
And that is the point of this topic of mine.
I understand the desire to improve the entire process of IPS development - but this process is slow and requires a lot of analysis and a lot of work.
Therefore, it is better to IPS restore access to all available css files in ACP.
When the IPS offers a successfully working project for the idea CSS to CDN - let this project go through online tests - who wishes to participate - and then go in for release...
I think so.

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."

Hopefully you realize that your "Fantastic" means that most of your "beautiful" complex layouts on your customer's sites will never make it to first page Google results because they have a boat anchor tied around their necks, from which they cannot escape--thus their hard work, articles, posts, etc., will sink to page 5...10...20...who knows how low? The longer you fail to address this, the more weight Google will put on sites with such speed issues, because that is what Google does.
Also, you didn't address the real issue here, which is stripping away my ability to do this myself--so far in this thread none of the arguments for doing this are convincing--why not allow users who want to do this to be able to continue editing their CSS? 

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.
Here is a speed test of this very forum thread--and you use CDN with zero ads running--you score a 51%, which is an F for FAILURE:

 
After mostly CSS changes made with the ability to edit CSS files directly--the feature you just took away from everyone (and with the help of @Adlago), here is a similar forum thread on my site--I have no CDN and am running a large number of graphical ads:

What you see here is a site with mostly CSS changes, and it scores 25% faster than a site that is on a CDN with no ads. How is that possible? Perhaps you need to hire @Adlago because apparently speed improvements are still not on your radar, and now you've gone out of your way to strip the ability for those of us who actually care about this issue to be able to do something about it ourselves.

I also cannot believe that you've removed this, and, after more than 15 years, and also looking at alternative boards to import my site into...totally unacceptable!
Your site speed is absolutely horrid...the only way I've been able to make my site get even average speed scores has been through extensive modification of CSS--now you've removed this ability from my--WHY??!!

For my part, I would be happy if all CSS were readable, as before, for reference even if not editable. The latest patch shows modified CSS and allows reverts of existing changes but unchanged CSS are still hidden and therefore, you can't use search.
It was so useful being able to search for something (even something as simple as a colour) and then quickly locate the code, copy it and then paste a modded version into custom CSS.

@Jordan Miller one idea might be to restore the editor, but make any change done to CSS export to overrides within the custom.css.  I find it helpful to understand what is there now so that I can see how/why you do something.  In fact, I might use something you do as a basis for something else in one of my Pages databases for continuity.  
Overall power users hate having tools taken away...  however there could be a way to allow power users what they're used to while still pushing the changes they make into the new system you want it to be without forcing them to just give up visibility in the first place.
Essentially I'm suggesting restore the editor...  when a change is submitted, parse it versus the original and send those changes to custom.css.  When viewing the editor again, load the diff and show the updated version.  

We have a free 3rd party app in our marketplace which could be used for this.
 

Hey @z929669,
Sorry for missing your message. I do indeed have a 4.4 compatible release, though it doesn't receive feature updates anymore.
I can either provide you with this version that you can install manually or I can have a refund processed for you if you prefer.

No, it's not like a post!! A post gets distributed to all users who are subscribed to that category, who can unsubscribe from such messages as they like.
The "share by email" feature on the other hand allows submission of random content to random email addresses.
I did send two very nice messages to support. If the best they can come up with is suggesting to disable the feature, I don't see how asking nicely for a third time is getting me anywhere.
(And just a hint: disabling the feature was nothing I couldn't think of myself before getting in touch with support.)
A feature that allows spamming random email addresses without giving them the option to unsubscribe violates CAN-SPAM, GDPR and probably evey other anti spam regulation in any other legislation too. And this is a feature currently provided by InvisionCommunity.

Hi,
I'm really sorry for your bad experience with this feature. We agree about your concerns here and have changed the way how this feature works for IPS 4.5.0

Invision Community Team: 
Thousands of emails are sent without control, the site email address is recorded in spam databases and your answer is "sorry, fix in 4.5"? You 've already tired us a little bit with blue message box about the new version, why don't you warn users with a red message box about this security hole?
 
 

I have a TESTINSTALL instance of IPS 4.x.x Forums upgraded from my previous IPB 3.4.6 forums and have made many changes to the ACP in terms of almost every setting, including building out new forums labels/structure/mods/perms, Menu Manager, etc.
I will be upgrading my production IPB3 instance soon and want to overwrite my ACP settings from TESTINSTALL if possible to avoid the repeat work. Using UPDATE on the core_sys_conf_settings table seems obvious and relatively risk-free ... any gotchas here?
What about other settings that likely require additional tables and meta-info like Menu Manager, Forum labels/structure, Member-Forum-Mod perms, Block config, etc? Perhaps it is safer to manually handle all of this, but wondering if anyone has devised a best practice(s) for this piece.
Thanks in advance.
 
------
Edit:
The following can possibly be updated using UPDATE ... SET from other instance
core_sys_conf_settings core_menu  
 

I have a TESTINSTALL instance of IPS 4.x.x Forums upgraded from my previous IPB 3.4.6 forums and have made many changes to the ACP in terms of almost every setting, including building out new forums labels/structure/mods/perms, Menu Manager, etc.
I will be upgrading my production IPB3 instance soon and want to overwrite my ACP settings from TESTINSTALL if possible to avoid the repeat work. Using UPDATE on the core_sys_conf_settings table seems obvious and relatively risk-free ... any gotchas here?
What about other settings that likely require additional tables and meta-info like Menu Manager, Forum labels/structure, Member-Forum-Mod perms, Block config, etc? Perhaps it is safer to manually handle all of this, but wondering if anyone has devised a best practice(s) for this piece.
Thanks in advance.
 
------
Edit:
The following can possibly be updated using UPDATE ... SET from other instance
core_sys_conf_settings core_menu