Somehow defaultStyle was not getting applied in all cases, but
defaultClass was getting applied in all cases. We don't have time to
investigate, but using a class is better anyways, so this change should
be fine.
Partially fixes#35129.
Prettier could not be used because of prettier issue number 12209, not
linked here to avoid spam backlinks on the original issue. Prettier does
not have support for mdx v2 and v3.
We are using remarkLintRulesLintRecommended and
remarkPresentLintMarkdownStyleGuide as our starting set of rules.
None of the rules were giving an error on the starting set, but some
rules were giving lots of warnings on the generated mdx. They are
set to false in this file, we can add them back later as and when
required.
We have not inserted this in the main lint tool, we should do that in
the final cutover PR since we don't want the lint here to give any
unexpected warnings when people are linting stuff unrelated to the mdx
files.
This commit has been tested out on the current state of help center to
not produce any errors or warnings. The first run of format will produce
tons of warnings which are the issues being auto-fixed by the linter.
After that, the second run should produce zero errors.
In some cases, some of the starlight css was inserting a margin top of
1rem to the svg tag inserted by unplgin-icons. We make the top margin
0 explicitly to make sure that extra margin is not added.
Slug was mentioned for the two entries in question as if they were
normal help pages, but they were external links and should have been
mentioned accordingly.
Having some options not set to true was causing hard to debug issues
when it comes to types. While that can be solved by changing `allowJs`
to true, it would be good to use the standard tsconfig they recommend in
order to avoid such issues in the future.
Fixes#31287.
These tags are not limited to just KeyboardTip, so we want to run the
transformation on all html.
We need to run the transformation client-side since the user's keyboard
style is only known at that time.
We had to override the HEAD component since that's what starlight
recommends to do if we want to include local assets on every page. If we
were using a remote js file, we could have modified the head config
option provided by starlight.
The script file to adjust the tags is mostly just copy-paste of the
original function to adjust for the lack of JQuery. Most of the comments
are also copy-pasted.
One change in the new script is to just use ⌘ symbol directly instead of
using zulip-icon since we don't have any centering problems in the new
help center.
Partially fixes#35130.
We will still need to do a second check before the cutover, but this
commit does most of the work before the cutover happens.
The comparison was done manually.
Added comment to sidebar index should help update these changes to astro
config, although we will not solely rely on people reading that. A
second check before cutover would be prudent.
Fixes#35119.
In the old help center, our css used to target each heading tag, h1, h2,
etc. individually. We don't need to do that anymore since the first
child of .sl-heading-wrapper is the heading element in starlight.
The rounded border on the top left and top right has been removed since
it did not look good with the default starlight theme.
Fixes#35116.
We copied whatever logic we needed from documentation_main.html. We have
not added the policy footer case from that html file into our footer
since that case does not apply to the new help center yet.
We process and pass the support email in the build help center step.
Even though we have separate packages for `help-beta`, we have opted to
put the prettier plugin and config for astro files in the main project
itself, so that linting needs to be configured only at one place.
Fixes#31253.
We've added another env variable called `SHOW_BILLING_HELP_LINKS`.
This env variable is set to `settings.CORPORATE_ENABLED` if the
`build-help-center` tool is used.
Fixes#31254.
We are using `SHOW_RELATIVE_LINKS` as the env variable to set if we
want to show relative settings link or non-linked markdown instructions.
We are not trying to determine `SHOW_SETTINGS_LINK` by ourselves. See
https://chat.zulip.org/#narrow/channel/49-development-help/topic/Passing.20sitename.20for.20astro.20project.20in.20production.2E
for more details.
Until the cutover happens, we would need to manually update the mapping
in both the astro component and the python file, but since that mapping
is not frequently changed, that is a tradeoff we can make.
We had to add margin-bottom: 0 to icon styling since starlight was
inserting a margin-bottom of 1.25 em for list items.
We want to follow the Astro way of doing things and the middleware was
adding more magic + it was violating commonmark spec:
https://spec.commonmark.org/0.31.2/#example-301.
We insert FlattenList component where include files are being
treated as part of ordered lists. Astro renders included files as it's
own component, which would result in multiple ordered lists instead of
a single list if we did not use this component. See the astro component
file itself to know more how FlattenedSteps works.
We are not inserting FlattenList component for files with !!! tip
components, since we need to do it inside the include file. There are 4
such files at the time of writing this comment.
`is_include_only_ordered_list` makes sure of that. We can do the
conversion for it manually during cutover or in a followup PR.
All unordered lists at the time of writing this comment are standalone
components and we do not need to do any transformation for them.
We also changed the order of conversion of include and main files.
Include files are now being converted first to calculate
include_files_info.
Relevant topic:
https://chat.zulip.org/#narrow/channel/19-documentation/topic/Stage.202.3A.20New.20syntax.20for.20imports
Fixes#34705.
We just copied the css from Steps component of Astro and applied it to
all ordered lists in our case. Future starlight upgrades have the
potential to break this css if they change the underlying variable
names, but the breaks would be obvious when testing the upgrade and if
it becomes a consistent issue, we can look into some other solution.
The reason we were doing string manipulation was that when using the
keyboard icon for KeyboardTip.astro, we were getting a blank spot if the
fill was not sent to currentColor. This commit instead passes the
currentColor for the imported unplugin icon directly. This commit only
addresses this specific component, any other instances of the icon color
being same as the page color still remain and this commit does not solve
that.
We also add unplugin types to tsconfig.json. We didn't need them before
since those types were not used in any astro components and were used in
mdx files directly instead.
We have an open PR to the upstream starlight repository to add support
for custom icons in the Aside starlight component. The PR is stalled
due to dependency on some of the custom icons work being done on
starlight. We should replace the code below with the Aside starlight
component along with a custom icon (keyboard in out case).
Not linking it directly to avoid necessary mentions on the original PR
whenever this commit is pushed. The PR number is 2261 in
https://github.com/withastro/starlight.
Earlier, we were just renaming the files in help/include and copying
them over. Which meant that none of the mdx features or any of the
components we add could be used there. We could also not support nested
imports which are a part of the help/include files.
We also set an explcit height and width of 1em for icons, since some odd
behaviour for icon height and width was noticed when writing this
commit. unplugin-icons sets height and width by itself. It was setting
the height to 1024 and 960 for some icons. It is better to set the
height explicitly.
In our app, we use the font-awesome stylesheet, add it to our webpack
bundle and use the appropriate class with the <i> tag.
Here. although for font-awesome, we can use the stylesheet to do the
same, we would need to use `webfonts-loader` for our custom icons.
In this astro project, we want to follow the Astro way, and
unplugin-icons fits better with the Astro way of doing things.
See this topic on the discussion on how we chose unplugin-icons:
https://chat.zulip.org/#narrow/channel/19-documentation/topic/Stage.202.3A.20Icons/near/2168842
Fixes#31252.
One of our major use cases for file imports is to have bullet points as
partials to import at different places in the project. But when
importing the file with Astro, it creates its own lists. So we merge
lists together if they have nothing but whitespace between them.
There were some talks to use a component called FlattenList that would
flatten the list inside it, but that would also flatten lists that were
nested on purpose. This approach while feeling a bit hacky would not
flatten nested lists.
We use all these markdown files in `include` only to import them into
our main help markdown files. Most of these files are bulleted lists of
text. When importing these files, they might appear as an indented
sublist of an existing list. We plan to introduce mechanism to flatten
it in further commits.
Instead of referring to users being added or removed from channels,
we now use subscribe or unsubscribed from channels.
Splits the article for adding and removing users from a channel
into separate articles: /help/subscribe-users-to-a-channel and
/help/unsubscribe-users-from-a-channel.
The URL redirects for the combined add/remove articles (for both
channel and stream terminology) go to the subscribe users to a
channel article.
