IDE

The in-browser IDE is the platform's built-in code editor for tweaking custom functions, workflows, templates, and small JavaScript snippets — all from within the admin panel, no separate IDE required.

What It Edits

• Custom API functions: Server-side PHP for bespoke endpoints.
• Workflow steps: Inline code that runs as part of a workflow.
• Triggers: Custom logic on data events.
• Email/document templates: HTML + template syntax.
• Dashboard block templates: Custom widget HTML/CSS/JS.
• Page builder snippets: Inline JS/CSS.

Editor Features

• Syntax highlighting for PHP, JS, CSS, HTML.
• Autocomplete for platform APIs ($AM->…).
• Inline linting.
• Find / replace across all snippets.
• Git-style diff of changes.
• One-click test runner with sample input.
• Roll-back to any previous version (every save creates a version).

Safety

• Code runs in a sandboxed context — no direct filesystem access outside designated paths.
• Time and memory limits per execution.
• Changes audited — every save logs the author and the diff.
• “Test in dev” option runs against the dev environment, not prod.

Worked Examples

• Quick fix: A custom function has an off-by-one bug. Edit in browser, save, redeploy in 30 seconds.
• Template tweak: Marketing asks for a different subject line on the welcome email. Edit, preview, save.
• Dashboard customisation: Add a new gauge to the operations dashboard via the IDE's block editor.
• Workflow refinement: Add a new condition to an existing workflow without round-tripping through git for a trivial change.

Editing custom code via the in-browser IDE feels lightweight but the code runs in production. A small set of disciplined practices keeps quick edits safe.

The Loop

1. Read: Open the snippet; understand what it does now. Don't skip this even for “quick” fixes.
2. Branch in your head: Imagine what the new code should do; check it against the existing behaviour.
3. Edit: Make the smallest change that achieves the goal.
4. Test in dev: Use the test runner with sample input.
5. Save: Creates a new version. Doesn't yet deploy.
6. Deploy: Activates the new version. Production starts using it.
7. Watch: Monitor error logs and performance for the next 15 minutes.

Things to Avoid

• Editing without reading: Surprises lurking in the snippet you didn't read.
• Deploying without testing: Even trivial-looking changes can break in subtle ways.
• Big refactors in the browser: The in-browser IDE is for small changes. Big refactors deserve a real editor and a real PR review.
• Skipping the audit trail: The platform records every change; don't shortcut by editing the underlying database.

When to Use a Real IDE Instead

• Changes that span 5+ files.
• Anything that needs unit tests.
• Code that warrants code review before going to prod.
• Refactors and renames.
• New features (use git, PRs, deployments).

Worked Examples

• Typo fix: In-browser is perfect — 30 seconds.
• Add a missing validation: In-browser fine — test in dev, deploy.
• Rename a function across 12 places: Real IDE, git branch, PR review.
• New API endpoint: Real IDE plus integration tests.