Table content

Some changes are visible right away.
Others matter because of what they quietly fix underneath.

LimeSurvey 7 Beta 1 falls firmly into the second category.

In this beta, we are rolling out a cleanup of how LimeSurvey names its response tables and fieldnames. It is not a flashy change. You will not see a redesigned interface or new buttons. But it touches one of the oldest and most central parts of the platform.

This article explains what changed, why we did it, and what you should check if you run plugins, themes, or custom integrations.

What is changing in LimeSurvey 7 Beta 1?

Over time, LimeSurvey’s internal naming for response tables and fields developed gradually. It worked, but it also led to patterns that were hard to predict and harder to build on.

With LimeSurvey 7, we introduce a consistent naming structure.

At a high level, this means:

  • Response tables now follow a clear and predictable naming scheme
  • Timing tables follow the same logic
  • Fieldnames use a consistent structure based on question and subquestion IDs

For example:

  • survey_<sid> becomes responses_<sid>
  • survey_<sid>_timings becomes timings_<sid>

Fieldnames now follow readable patterns such as Q<questionId> or Q<questionId>_S<subquestionId>

Nothing changes about how surveys behave or how responses are collected. This is a structural cleanup, not a functional rewrite.

Why touch this at all?

Because these naming patterns sit at the foundation of everything else.

Plugins, custom themes, JavaScript snippets, reporting queries, and integrations often rely on response tables and fieldnames. When those foundations are inconsistent, every layer above becomes harder to maintain.

Structural changes like this are rarely simple. They touch parts of the system that have existed for a long time and that many extensions rely on. That is also why teams often postpone this kind of work.

But consistency and predictability are essential for long-term stability. Without them, every new feature becomes more expensive and more fragile over time.

This cleanup gives LimeSurvey a base we can confidently build on going forward, even if the change itself is mostly invisible on the surface.

Who should pay attention to this beta?

If you use LimeSurvey out of the box, this beta will likely work without any changes.

You should take a closer look if you run:

  • Custom plugins
  • Custom survey or admin themes
  • JavaScript that references response fields directly
  • Reporting dashboards or scripts that read from the database
  • Any custom integration you built yourself

These setups may need small adjustments to align with the new naming.

How to test it safely

We strongly recommend testing this beta in a separate environment.

A typical test setup looks like this:

  1. Download the latest LimeSurvey 7 beta from community.limesurvey.org
  2. Install it separately from your production system
  3. Import your surveys, themes, and plugins
  4. Check whether everything behaves as expected
  5. Update any code that relies on old table or field names

For developers, LimeSurvey also provides a helper function called 'getFieldName()' that lets you preview how an existing field will be named after the upgrade. This makes it easier to update plugins and integrations ahead of time.

Help us stabilize the final release

Early testing is how we avoid surprises later.

If you spot anything that looks off, please report it via our bug tracker at bugs.limesurvey.org. Even small reports help us catch edge cases before the final release.

Final thoughts

This beta is about making LimeSurvey more predictable and easier to maintain in the long run. It is a careful cleanup of internal structure, not a visible redesign.

If you are running LimeSurvey with plugins, themes, or custom integrations, your feedback at this stage is especially valuable. Thanks for helping us make LimeSurvey 7 solid from the inside out.