Skip to Content
Last modified by Agnease on 2026/05/26 11:00
From version 12.5
edited by Agnease
on 2026/05/26 11:00
Change comment: There is no comment for this version
To version 12.1
edited by Agnease
on 2026/05/26 10:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -110,15 +110,6 @@
110 110   for related checks around permissions, authentication, extensions, infrastructure and operational practices.
111 111   </p>
112 112  
113 - <div class="resource-inline-cta">
114 - <p>
115 - <strong>Unsure how maintainable your XWiki customizations are?</strong>
116 - A customization review can help identify hidden scripts, undocumented logic,
117 - upgrade risks and features that should be documented, cleaned up or packaged properly.
118 - </p>
119 - <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a customization review</a>
120 - </div>
121 -
122 122   <h2 id="safe-model">A safer model for XWiki custom work</h2>
123 123  
124 124   <h3>1. Keep custom code separate from standard XWiki pages</h3>
... ... @@ -185,15 +185,6 @@
185 185   </p>
186 186   </div>
187 187  
188 - <div class="resource-inline-cta">
189 - <p>
190 - <strong>Not sure how risky your current XWiki version is?</strong>
191 - A short technical review can clarify the upgrade path, extension compatibility,
192 - custom code risks and validation needs before production is touched.
193 - </p>
194 - <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick review</a>
195 - </div>
196 -
197 197   <h2 id="practical-checklist">XWiki custom development checklist</h2>
198 198  
199 199   <p>
... ... @@ -225,50 +225,40 @@
225 225  
226 226   <h2 id="custom-development-faq">XWiki custom development FAQ</h2>
227 227  
228 - <details class="resource-faq-item" open>
229 - <summary>Does custom development make XWiki harder to upgrade?</summary>
230 - <p>
231 - Not automatically. Custom development becomes harder to upgrade when it is undocumented, mixed with regular
232 - content, applied directly in production or missing from the upgrade validation plan. Well-organized custom work
233 - can remain maintainable across upgrades.
234 - </p>
235 - </details>
210 + <h3>Does custom development make XWiki harder to upgrade?</h3>
211 + <p>
212 + Not automatically. Custom development becomes harder to upgrade when it is undocumented, mixed with regular
213 + content, applied directly in production or missing from the upgrade validation plan. Well-organized custom work
214 + can remain maintainable across upgrades.
215 + </p>
236 236  
237 - <details class="resource-faq-item">
238 - <summary>Where should XWiki custom code be stored?</summary>
239 - <p>
240 - Custom wiki pages, scripts, templates and configuration should usually be kept in dedicated technical spaces.
241 - Code and important assets should also be tracked in a source control system, such as Git, so changes are not
242 - stored only in the production wiki.
243 - </p>
244 - </details>
217 + <h3>Where should XWiki custom code be stored?</h3>
218 + <p>
219 + Custom wiki pages, scripts, templates and configuration should usually be kept in dedicated technical spaces.
220 + Code and important assets should also be tracked in a source control system, such as Git, so changes are not
221 + stored only in the production wiki.
222 + </p>
245 245  
246 - <details class="resource-faq-item">
247 - <summary>When should an XWiki customization become an extension?</summary>
248 - <p>
249 - Packaging a customization as an extension is useful when the feature becomes complex, reusable, business-critical
250 - or shared across multiple instances. Java components, event listeners, scheduled jobs and integrations often
251 - benefit from an extension-based approach.
252 - </p>
253 - </details>
224 + <h3>When should an XWiki customization become an extension?</h3>
225 + <p>
226 + Packaging a customization as an extension is useful when the feature becomes complex, reusable, business-critical
227 + or shared across multiple instances. Java components, event listeners, scheduled jobs and integrations often
228 + benefit from an extension-based approach.
229 + </p>
254 254  
255 - <details class="resource-faq-item">
256 - <summary>What should be tested after an XWiki upgrade?</summary>
257 - <p>
258 - Besides standard pages, the validation should include custom dashboards, templates, macros, workflows,
259 - permissions, notifications, PDF exports, scheduled jobs, integrations and any custom applications used by the
260 - organization.
261 - </p>
262 - </details>
231 + <h3>What should be tested after an XWiki upgrade?</h3>
232 + <p>
233 + Besides standard pages, the validation should include custom dashboards, templates, macros, workflows,
234 + permissions, notifications, PDF exports, scheduled jobs, integrations and any custom applications used by the
235 + organization.
236 + </p>
263 263  
264 - <details class="resource-faq-item">
265 - <summary>Why should configuration be kept outside custom code?</summary>
266 - <p>
267 - Values such as group names, target spaces, external URLs, email recipients and workflow settings can change over
268 - time. Keeping them in configuration pages or preference objects makes custom features easier to adapt without
269 - changing the implementation.
270 - </p>
271 - </details>
238 + <h3>Why should configuration be kept outside custom code?</h3>
239 + <p>
240 + Values such as group names, target spaces, external URLs, email recipients and workflow settings can change over
241 + time. Keeping them in configuration pages or preference objects makes custom features easier to adapt without
242 + changing the implementation.
243 + </p>
272 272  
273 273   <div class="resource-note">
274 274   <p>