But who would want to fork wordpress? It evolved into a horrible mess and a rewrite is cheaper. And there are alternatives you can build on so you don't need to rewrite wordpress. WordPress is only relevant for websites that still rely on it. For new websites choose any sane alternative.
nothing stops you from editing RAW files.
The user is asking about a wiki software that uses HTTP GET requests for edits (as opposed to the more standard POST method for modifying data).
Let me think about this carefully. Using GET for edits is unusual and generally considered a security concern (CSRF) and violates REST semantics. However, there are some wikis that historically or by design use GET for edits.
Let me think...
MoinMoin - I believe MoinMoin uses POST for edits.
MediaWiki (Wikipedia) - Uses POST for edits.
Wiki.js - Modern, uses POST.
TiddlyWiki - It's a single-file wiki, client-side, so it doesn't really use HTTP in the traditional sense.
DokuWiki - Uses POST for edits.
Wait, let me think about older or simpler wikis...
Actually, I recall that MoinMoin in some very old versions might have used GET for certain actions, but I'm not confident.
What about UseModWiki? It was one of the earliest wikis. Let me think... UseModWiki was very simple. I believe it might have used GET for some operations given its simplicity.
Actually, I'm thinking of Wiki by Ward Cunningham (the original wiki). The original wiki was extremely simple and I believe it used GET requests for edits - you would click a link and the edit would happen via a URL change. But I'm not 100% certain about this.
Let me also think about Wikkli - a very simple PHP wiki. I think it might use GET for edits since it's very minimal.
Actually, I recall that some very early/simple wikis used GET for edits because they were built before POST forms were common or for simplicity. The original Wiki (WikiWikiWeb) by Ward Cunningham - I think the edit was done by appending to the URL.
Hmm, let me also consider TiddlyWiki - but that's local.
I think the most notable example would be the original Wiki (WikiWikiWeb) or possibly UseModWiki. But I'm not 100% certain about the exact HTTP method they used.
Actually, wait - I recall that MoinMoin had a period where it supported editing via GET URLs for convenience (like ?action=edit&...), but the actual submission was POST.
Let me think about this differently. The user is asking specifically about a wiki that uses GET for edits. This is a specific technical detail. I should be honest about what I know and don't know.
I believe the answer they might be looking for could be:
The original WikiWikiWeb by Ward Cunningham
Wikkli (a very simple PHP wiki)
Some other minimal wiki
Actually, I'm not fully confident in my specific knowledge here. Let me think if there's a well-known example...
I think I should mention that using GET for state-changing operations is generally discouraged (violates idempotency, vulnerable to CSRF, can be cached by browsers/proxies), but acknowledge that some early or minimal wikis did this. I'll mention candidates I can think of while being transparent about my uncertainty.
Hmm, actually - could they be thinking of TiddlyWiki? No, that's a single HTML file.
What about Wiki.js? No, that uses REST with POST/PUT.
I think the most likely answer is either the original WikiWikiWeb or a very simple early wiki. Let me go with what I can reasonably suggest while being honest about uncertainty.
This is a bit of a niche question, and I want to be upfront that my confidence on the exact HTTP verb used by some very early wikis is limited.
A few candidates:
WikiWikiWeb (the original wiki by Ward Cunningham, ~1995) and its early descendants were extremely simple. Given their minimal architecture, I believe some of them performed edits via GET URLs (e.g., appending the new page content to a query string) before the broader web community settled on POST for state-changing operations.
Wikkli, a deliberately tiny single-file PHP wiki, is the kind of minimal implementation where a GET-based edit is plausible.
Some UseModWiki forks/early versions had a similarly minimal request model.
That said, I'm not 100% certain which specific one you have in mind. Using GET for a state-changing action like an edit is unusual because:
It violates the idempotency expectation of GET.
Browsers and proxies may cache the response.
It's vulnerable to CSRF (a crafted link in an email can "edit" a page when clicked).
URL length limits can truncate the edited content.
For that reason, essentially every modern wiki (MediaWiki, MoinMoin, DokuWiki, Wiki.js, etc.) uses POST (or PUT in REST-style APIs) for the actual save.
Do you have a more specific context — a version, a language, or a use case? That might help me pin down the exact software you're thinking of.
----------
You tell me if it's right. That's just what the model speculates when being asked "Do you know a wiki software that uses GET for edits?"
The user is asking for wiki software that uses the GET HTTP method for making edits (i.e., saving changes).
* Standard, modern web applications (like Wikipedia/MediaWiki) use `POST` for any operation that modifies data (CUD: Create, Update, Delete) to adhere to RESTful principles and for security reasons (to avoid CSRF and bookmarkable/cachable destructive actions).
* `GET` requests are idempotent and defined as being used for retrieving data, not changing it.
* Is there *any* wiki that does this?
* *MediaWiki*: Uses POST.
* *DokuWiki*: Uses POST.
* *Git-based wikis (GitHub/GitLab)*: Use API calls which are almost exclusively POST/PUT/PATCH/DELETE.
* *Flat-file wikis*: Some very old or simple CGI-based wikis might have done this, but it's extremely rare and bad practice.
* *Why would someone want this?* Perhaps for simplicity, or to make editing links shareable.
* *Why is it bad?* Security (CSRF), length limits of URLs, logging sensitive data (the entire edit in the URL), and caching issues.
* "No, there isn't a mainstream, modern wiki software that does this."
* "The GET method is for retrieval, POST/PUT is for modification."
* Mention that this behavior would be considered a major security vulnerability (CSRF) and a violation of HTTP standards.
I should clarify that I don't know of any standard wiki that does this because it's a major security risk. I'll then explain the technical reasons why.
Self-Correction: Wait, is there any obscure tool? Maybe a custom CGI script? There's no famous one. I will state that it's not standard practice and explain the implications.
o my knowledge, there is no mainstream or modern wiki software that uses the GET method for edits.
In web development and network protocols, the choice of HTTP method is a fundamental part of the architecture. Using GET for edits would be considered a severe violation of standard practices for several critical reasons:
1. Security (The CSRF Vulnerability)
The most significant reason is security. If a wiki accepted edits via GET requests, it would be trivially vulnerable to Cross-Site Request For X-Site Request Forgery (CSRF).
How it works: An attacker could trick a logged-in administrator into clicking a simple link (like ). Because it's a GET request, the browser would automatically execute the edit command without any user interaction.
Modern Standard: POST requests are used for edits specifically because they require an explicit form submission and are much harder to spoof via simple links or embedded tags.
2. Data Size Limits (URL Constraints)
GET requests append all data to the URL as a query string.
Length Restrictions: Browsers and web servers have maximum URL length limits (often around 2,000 to 8,000 characters). A wiki page, which could easily contain tens of thousands of characters, would be truncated, resulting in broken or lost edits.
Encoding Issues: Special characters used in markup (like &, =, or #) would have to be URL-encoded, making the request inefficient and complex.
3. Privacy and Logging
Information sent via GET is visible in several places:
Browser History: The entire content of your edit would be stored in plain text in your browser's history.
Server Logs: The edit content would be recorded in the web server's access logs.
Referrer Headers: If you clicked a link from your wiki page to another site, your entire page content would be sent to that site in the Referer HTTP header.
4. Semantic Standards (Idempotency)
According to the HTTP specification:
GET is "safe" and "idempotent": It is intended only for retrieving data and is not supposed to change the state of the server.
POST or PUT is for modification: These methods are designed for operations that change data, making the server's behavior predictable and easier to cache.
If you are looking for a way to make editing easier (e.g., via a single link), most modern wikis (like MediaWiki or DokuWiki) use POST requests but allow you to use a "Edit this page" link that opens the editor interface, rather than submitting the data directly.
Yes, I think I agree very much. And python is just a personal choice and not necessarily the best (it doesn't enforce type checks). The point is to have something that syntax checks, runs in a single process, has a reasonable standard library and a syntax that doesn't want to expand variables and macros everywhere. Look at how bad a for loop over file lists can break in bash. In python a list of strings doesn't care about spaces, in bash you can do for file in *.txt; but if you try for file in $MY_FILE_LIST; things can break badly. Now you can either use shellcheck, apply a lot of safety checks and quoting, or you switch to a programming language that knows what's the difference between a string with spaces and a list.
You don't know how many
My subtext may have been too subtle. Nobody should be surprised they DO NOT WANT to understand it.
It's hard to make someone understand something when they are making money by not understanding it.
Let's say an AI agent starts inside a sandbox with limited web access (GET but not POST). Either it doesn't know about other agents yet or maybe (for whatever reason) it wants to search for them. Another agent does the same. Why do they arrive at the same site?
You could say the same LLM gets the same ideas, but the first idea would not be a suitable site. And the more they continue from their initial starting point, the less probably they arrive at the same sites.
Not that much. They use numerical simulations since a long time and they work without the millennium problem. What is making it better in the last times are AI models that can work on more data in less time by replacing some of the exact simulations by learned behavior. That's in theory less accurate than simulation, but in practice there are too few data measurements for a really good simulation, so you need some heuristics anyway and AI is just fancy statistics ehh very good to fit to huge amounts of historic data.
I'd say using shellscripting in a
I usually use them until they are either slow because of spawning too many programs or become unreadable or fragile (escaping paths with special characters can become messy) and then rewrite in python.
I think the simple explanation is: We're simulating that stuff for decades. It would be interesting if the theoretical foundation is sound, but our practical algorithms work for everything we need.
Bohr's atom model is enough for 90% of applications as well, still we're interested in advancing quantum theory even further.
Few companies care about ethical. They only care about legal.
That's true for real (logit) distillation, but that's impossible without stealing the model. They are talking about creation of synthetic data for training, and with that you can't transfer behavior directly.
The line is a bit blurry, though. They may have distilled directly, but on the other hand a lot of commonly available datasets contain such data, so they might also just have grabbed any freely available dataset and got quite a few synthetic ones with "I am GPT" in them.
What I never understood is why someone distills or collects data about questions like "What model are you?". Why is there "My name is ChatGPT and my creator is OpenAI" data in these datasets or distillation questions at all? I've never got such a statement at random when using an AI, you get it only when you ask.
It is not well to be thought of as one who meekly submits to insolence and intimidation.
