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

Summary

Details

Page properties
Content
... ... @@ -110,6 +110,15 @@
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 +
113 113   <h2 id="safe-model">A safer model for XWiki custom work</h2>
114 114  
115 115   <h3>1. Keep custom code separate from standard XWiki pages</h3>
... ... @@ -176,6 +176,15 @@
176 176   </p>
177 177   </div>
178 178  
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 +
179 179   <h2 id="practical-checklist">XWiki custom development checklist</h2>
180 180  
181 181   <p>
... ... @@ -207,40 +207,50 @@
207 207  
208 208   <h2 id="custom-development-faq">XWiki custom development FAQ</h2>
209 209  
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>
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>
216 216  
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>
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>
223 223  
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>
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>
230 230  
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>
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>
237 237  
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>
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>
244 244  
245 245   <div class="resource-note">
246 246   <p>