It looks like you're new here. If you want to get involved, click one of these buttons!
for themes to appear in the mobile theme choices instead of desktop choice.
addon.json add line
from the docs....
While PluginInfo and ThemeInfo declarations are deprecated, they will still be supported for some time. Aside from the syntax differences between JSON and PHP, the structure and key names are very simple.
although the other tips are helpful for the future and may fix things for it to work for third party themes.
The docs may say that it's still supported, but that's not my experience up until now. With addon.json plugins work, without them plugins that worked fine in 2.3 fail in 2.5 (at least in my specific setup).
won't argue with you there.
the code I posted worked in my environment for Bittersweet and 2.5.1 without the changes you proposed.
but if your changes make things work with Bittersweet and Glass themes in more environments, than that is the best of both worlds and helps the user solve their problem.
I believe I found it - Application > Vanilla > Settings > configuration.php. Interestingly none of the configuration settings change when these settings are changed from the Dashboard.
don't change that file as per the iinstructions in the file.
Also, any announcement discussions on the main page are automatically combined with the total number of discussions on that page. Example - if there are 3 announcement discussions on the first page and 10 discussions should be maximum limit per page, then 13 discussions show up on first page. Can this be fixed?
True, the count of discussions per page is exclusive of announcements.
you can change config settings are in conf/config.php
you can add them if they are not there e.g.
['Vanilla']['Discussions']['PerPage'] = '5';
for examples of config statements and other info see
you could study
vanilla / applications / vanilla / models / class.discussionmodel.php
which is where announcements are probably filtered
then override the info with a plugin. imho its not worth the effort.
Probably the smoothest release yet and easiest upgrade. and the best upgrade documentation thus far. nice improvements. Looking forward to 2.4
The options I like best are to either start a 2.4 release cycle immediately (without the native API) and continue on the 2.x "point" releases, or wait for the API v2 feature and increment directly to a 3.0 release. Why 3.0? I think rebuilding all our innards & our Dashboard from scratch with a full native API counts as a product refresh. It's not a huge backwards-compatibility break nor a restart like 2.0, but I feel like it would give folks a reason to have a second look at Vanilla if it's been a while.
A year after my last update, I also worry about increasing the pace of our releases. We still have some major addons not compatible with 2.3 a month after its release and after a 6-month testing period. That leads me to believe we don't have critical mass for a more aggressive release schedule. Also, it's very stressful and time-consuming to do a major release for our small team. Hitting annually or slightly better seems like a nice compromise. The 3.0 plan gets us closer to that pace.
I'm currently leaning strongly in the direction of a 3.0 release in 9 months or so, but nothing is set in stone. Constructive feedback welcome.
I'll do my best to provide constructive ffedback.
I like best this option: a 2.4 release cycle immediately (without the native API)
while api could be great, the other functionality in 2.4 and bug fixes, core plugins would be nice to get out in a timely manner, since as you say now is the optimal time to start a release cycle if you are going to do a 2.4 release.
A year after my last update, I also worry about increasing the pace of our releases. We still have some major addons not compatible with 2.3 a month after its release and after a 6-month testing period. That leads me to believe we don't have critical mass for a more aggressive release schedule.
From user testing standpoint, the testing period at least by a large group of users was probably small, because incremental changes are not downloadable by zip. The burden of a build and github, may be a deterrent to a larger number of users than you think. Whereas, a downloadable (workable w/o build) zip from github at incremental points would give your test user base several orders of magnitude larger.
We still have some major addons not compatible with 2.3 a month after its release
I don't think basing vanilla releases on third party add-ons is a benefit. Plugin authors will always abandon add-ons, this is a fact of life. If the add-ons are significant and help market vanilla why not co-opt the add-ons and fix them. if a third party add-on causes you to think about altering a release don't worry about the add-ons, or produce your own add-ons that mimic the third party add-ons that you feel are important enough to delay a release. Waiting 3 more months in a release cycle probably won't fix a broken third party add-on.
Downloadable working vanilla zip of alpha, beta or rc without a build would go a long way in average user testing and give you the largest test base.
Also, it's very stressful and time-consuming to do a major release for our small team.
understood, you need to do what works best for you.
since you state:
I'm currently leaning strongly in the direction of a 3.0 release in 9 months or so, but nothing is set in stone.
The reason I suggest against this is because guestimations of release dates are usually more optimistic leaning than realistic leaning for all types of software as well as vanilla software. There are always unknowns. and this could stretch out well beyond 9 months. Look back at your own time predictions and see if I might be correct.