Publishing

Publish, in the editor, sends the article to its site. It always saves the local article first, so a failed or cancelled publish never costs you your latest edits, and it asks you to confirm before anything goes out.

What happens, in order

Grafida shows each step as it reaches it:

1. Preparing. The site's token and API address are resolved, and the site's custom fields are narrowed to the ones that apply to this article's category.
2. Uploading images. Any picture still held only on this machine — the intro image, the full article image, a picture custom field, or one used inside the body — is uploaded to the site's Media Manager, into the filesystem and folder set on the site. The body is then rewritten to point at the uploaded copies, and that rewrite is saved locally so a second attempt does not upload everything again.
3. Resolving tags. Tags that match one of the site's existing tags are matched to it; the rest are created.
4. Resolving images. The intro and full article images are turned into the paths the site knows.
5. Mapping custom fields.
6. Writing the article. Title, alias, body, category, access level, language, status, tags, custom fields and metadata go over as one request, creating a new article or updating the one this article is already linked to.
7. Verifying. Grafida checks that what came back really is the article it just wrote, rather than something a redirect or a proxy substituted.

The title, body and metadata have invisible characters removed on the way out, according to the Normalise AI-generated content setting — see Settings. Your local copy is not changed by that.

Cancelling

Cancel is available while the earlier steps run. Cancelling stops Grafida before the article is written, and it says so plainly: any pictures already uploaded stay in the site's Media Manager, and the article itself was neither created nor updated. There is no way to ask a site to take an upload back.

When Publish is blocked

Some sites require a custom field of a type only Joomla's own back end can edit — a field from a plugin, most often. Rather than publish an article with that field silently blanked, Grafida stops and names the field. From there:

• Finish the field in the site's back end and publish again, or
• Publish anyway, which sends back the value the field had when the article was downloaded, unchanged.

Publish anyway is offered only when every blocking field actually has such a value. Where Grafida holds no value at all it says so, and offers Copy HTML so you can finish the article in Joomla's back end instead.

It is a confirmation rather than something automatic because Grafida cannot display those fields, and so cannot tell you whether their values have changed on the site since the article was imported.

If the site rejects it

Joomla's own message is shown exactly as it came back, because nothing else identifies the field it is complaining about. Reload metadata is offered beside it, since a common cause is a category, tag or field that has changed on the site since Grafida last looked.

The other common cause is permissions. A token authenticates as its user, and that user's ordinary Joomla permissions still govern everything — publishing into a category the account cannot write to fails on the site, not in Grafida.

After a successful publish

The article stays where it is, now linked to the article on the site, and further edits publish to the same one. Grafida re-reads it so that the body it shows you is the one that was actually stored.

If you would rather not keep the local copy, delete it from the editor with Delete Local Article — that never touches the article on the site.