Sisyphus revision: Wiki leaks in #192
Conversation
Reqrefusion
force-pushed
the
leaking_wiki
branch
from
e40a59c
to
16052fb
Compare
|
That's VERY impressive :) It might not be ideal though, because people cannot edit, and I suppose links from inside the wiki won't work unless we add apache rules to catch everything, but again that removes the ability for people to change the theme, etc.. But let's keep this around anyway, it's amazing that it's possible with so little code |
Actually, all the links in the wiki are functional @yorikvanhavre . It is meaningless without that system. However, I did not share it because of a ridiculous problem that arose from my own site. It will work properly on FreeCad's own website. You can visit the entire wiki from here. It also works in translations. No lie, it was more difficult to do this process than to shorten the codes that do it. And of course, finding the title. |
Reqrefusion
force-pushed
the
leaking_wiki
branch
from
1491072
to
e1bf8e4
Compare
ScreenRecorderProject1_696.mp4You can see how to navigate here. As you can see, it offers a seamless experience. On my site, some site images are not visible because the links are given relatively, but this will not happen in Freecad. I also ensured that the site's translation system is functional within the wiki. |
Reqrefusion
force-pushed
the
leaking_wiki
branch
3 times, most recently
from
c2d238c
to
32cabcf
Compare
|
I am proud to say that it has now reached its mature state. I have tested it on over 500 pages and I can say that the most accurate transfer has been made here so far. My favorite part is probably that it is compatible with the current style of the site. It is almost impossible to tell that it is something completely different. |
Reqrefusion
force-pushed
the
leaking_wiki
branch
2 times, most recently
from
1418b12
to
e6f6282
Compare
|
It's really impressive and great to have as an alternative to the wiki itself. Especially since in previous months there have been quite a few cases of the wiki being painfully slow for multiple days. What I lack here (apart from alternative themes) is having more ways to navigate (search bar, side bars and so on) but I guess it could be added later on. I also wonder how frequently this could be synchronized with the wiki since edits are made almost each day. Some good offline form of the documentation would still be needed but for now, at least we won't have to rely on the wiki itself to access the manual. |
|
Pretty and practical. |
This is fetched online, there is no synchronization needed, so changes are reflected immediately. However, unfortunately, since each page requires a wiki access, it will be as slow as the wiki itself... |
If desired, a page can be cached by using it and it will remain for the desired number of days. I don't know if this is something desired or not, it is not very difficult to do. Is it a choice to always use the current page or to have the page loaded faster? You can see how this can be done #194 . |
|
Thanks, this is a nice addition. Of course, like @FEA-eng, I miss certain Wiki features when browsing the documentation in this manner. Would it be possible to have a solid background color instead of the 'zigzag' image for these pages? I find blue texts on dark backgrounds hard to read. I do not know if others experience the same. |
|
Ideally, at the bottom of each page, there would also be a link to the corresponding wiki page, so the person could read that one instead if for some reason something is not rendered correctly |
Reqrefusion
force-pushed
the
leaking_wiki
branch
from
3b6d96b
to
0a1e7de
Compare
Sorry, I didn't explain my purpose fully, so it may have been a problem. The purpose here is to provide an integrated experience by not redirecting the internal links to different places. In other words, adding more features only bloats it. Therefore, even if more features can be added, it would be right not to add them.
For this, the entire site needs to be changed. It is better to have the same experience on the entire site for an integrated experience. There is already another project to do the whole site.
Yes, there is. Because this project is actually built on the privacy and code to conduct pages. |
|
Own background makes this project fascinating. 🏆
In my opinion, the layout and readability is good. 🤩 |
hash links now work Some style Update wiki.php Update wiki.php [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci Adjusting the colors of the code section. [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci Update wiki.php
Reqrefusion
force-pushed
the
leaking_wiki
branch
from
0a1e7de
to
a5c53ba
Compare
for more information, see https://pre-commit.ci
The background ruins the complete experience for me, for the complete website. And multiple people here have complained about it. Not sure why it's still there? Do you guys check how the website looks on mobile? |
|
I understand the backlash for the background, but this PR is not about the background. The current background has problems, but it also has a soul, removing it and giving it a single color will destroy this soul. I can work on it, but I haven't gotten a result that I feel comfortable with so far. |
|
You can ask the team from ui-ux-themes from the discord platform for support. There are some cool people there who might be willing to help you (and not just complain). https://discord.com/channels/870877411049357352/870883914191888444 |
|
The background triggers me so badly that I have issues with staying on topic😅. Just remove the zigzag, we can discus which color to use after it. |
|
I generally dislike concept of connecting services in that manner. It will be really hard to ensure that it looks good both on wiki and on the site - basically it is asking for trouble. Basically it is a gimmick, seems nice but will generate more problems than it is worth. Wiki styles are done for wiki with some assumptions (as everything is) like using it on white background etc. You can download styles from wiki and override some values (like text color) but this is prone to errors. For this site you have blue background - if anything on wiki will be done in blue color it will not be visible on the background. Reds won't work either. You cannot possibly control such wide spectrum of style changes. Finding page with blue text on blue background took me literally one click. Can you change the background here to be white? Sure, but then you can have styles on main page that will collide with wiki. For example - fonts are enormous (for me it looks like 300% of scale) and are icons are not scaled accordingly. Containers for the text are also not scaled accordingly: The box on the right has Finding these examples took me like 3 minutes, even if they will be fixed somehow there will come more. For me it is only a gimmick that will look bad no matter how much work we put in as the concept of connecting sites in that matter simply results in endless issues because no one designs sites to be used like this. |
|
This is a matter of taste. It's a matter of liking or disliking something like this. It's pointless to use it for some documentation related stuff, but it's a nice bonus for release notes. It's not really true that nobody would design it this way, but it can be adjusted within mediawiki. The diversity of mediawiki users has always been mind-boggling. The work here is done by external intervention, without any internal adjustments. |
|
Blue text on blue background is not a matter of taste. Box size that barely fits one word is also not a matter of taste. It is a matter of usability and accessibility. Of course you can design for two vastly different designs - but should you? Forcing all wiki editors to check both is adding unnecessary work for people, who are already quite occupied. Many will not even remember to check this site as they work on a different platform. I don't see any real advantage of putting the whole wiki accessible in that way, Why to go with all this trouble, do we really need it and benefit from it in any way? Some pages like release notes? Sure! We can adjust them to look good on both. But wiki as a whole seems like a lot of trouble, potential errors and problems for a little to no gain. My proposal is to limit this mechanism to some cherry-picked pages like release notes mentioned earlier. This way we will be able to control and adjust the page to look decent on both platforms. It will also bring some benefit as release notes should not require going to a different platform. |
|
Actually, I said it was a matter of taste, not for those mistakes, but for such a concept. Such a thing already involves a huge question of why, the only possible answer is to say I do it because I can. |
|
Hi there ! It is quite impressive indeed to see how such two different platforms can be somewhat reunited. Well done ! However, I'm a bit of the same opinion as @kadet1090 , I'm not convinced the added complexity to try to force/hack this to work properly is worth the little added value (having the whole wiki displayed without leaving the main site). The current wiki already has its share of issues, so adding another layer without getting to the "real root" seems counterproductive. Nevertheless, this effort has the positive effect of stimulating conversation on the wiki question even more. Perhaps after the busy period of the 1.0 release, a major in-depth discussion on the whole documentation topic with the relevant stakeholders (some of whom have commented here) is in order ! Bruxelles 2025 ? =D |
|
Thanks, @marcuspollio . Actually I wasn't even thinking of sharing such a project but I did a PR like this because I liked how it was progressing. I have much better ideas for the wiki than this, I'm working on a better project since I've been very close to mediawiki in the past. When working with such a large documentation about adding complexity, every solution requires complexity. The reason I like the solution here is partly because I achieved such a compact result on such a structure. |
|
I am for having a backup wiki. But it should be protected from syncing if wiki ever goes down. Because it's nice to be independent but it would fail terrible if it cleans out the backup because the source is gone. |
|
It's a shame there's no demand for something like this. I don't see it possible to make it in a form that everyone will accept. I have made progress on the offline copy of the wiki that most people are mainly interested in. You can access it here: https://github.com/Reqrefusion/FreeCAD-Documentation-Project. It is constantly updated according to changes in the wiki. |
|
Honestly I think there is a lot here that depends on the future solution chosen for the documentation. If we go away from the wiki, then I would prefer to not merge this right now as it might break and need to be redone later. |
Now the wiki is inside the site. Quite impressively, I finally got the wiki to show up on the site. The entire wiki and its translations can now be viewed on the site. Funnily enough, this is the only place where you can read the wiki responsively. While I spent a lot of effort to make many pages look good, I did take care of the pages that redirect to the wiki on the site. I made some changes to the .htaccess for these. It looks like we transferred all the pages from the wiki to the site. I love this magic.
This project is mostly pointless, isn't that why it started in the first place? But the fact that it is impressive doesn't change.
Screenshots
There are still problems, but I'm not sure if this is something that needs to be fixed or abandoned.
You can check it out here, but I didn't set up the link structure here, so you'll need to change the url.