WordPressカスタム投稿タイプの開発記録｜WAFによる保存失敗の調査とFTPフォールバックの実装

WordPress Custom Post Type Development Log: Investigating WAF-Related Save Failures and Implementing an FTP Fallback

This article was structured and written with the help of ChatGPT, based on actual FUKABORI COLORS development records.

This article documents the migration of FUKABORI COLORS' Devlog from static HTML files managed via FTP to a WordPress custom post type.

The development took place from September 28 to October 8, 2026. It involved integrating with WordPress and Cocoon, switching between Japanese and English, saving monthly summaries, and improving related-content links.

One of the main challenges was that English body content and monthly summaries could not always be saved through the WordPress admin interface. After investigating the issue and testing several approaches, an FTP-based fallback was implemented.

1. Project Overview

FUKABORI COLORS previously maintained its Devlog as static files managed via FTP. The goal was to move the system into WordPress so that development records could be managed and updated more easily.

The main environment and components were:

• CMS: WordPress
• Theme: Cocoon with a child theme
• Hosting: Lolipop!
• Custom post type: fc_devlog
• Dedicated plugin: fukabori-devlog.php

The aim was not simply to import old articles. The new system needed to support monthly development records, Japanese and English content, monthly summaries, and links to related content.

2. Integrating the Custom Post Type with Cocoon

The first stage was to build the dedicated custom post type and its display templates.

Monthly archives, individual articles, related content, and visual styling were developed while checking for conflicts with Cocoon's existing features.

Several issues appeared during development. Featured images sometimes appeared despite being set to hidden, English content was missing, and the table of contents appeared where it was not wanted.

These issues did not all share the same cause. The saved post data, template output, and theme-level display processing had to be checked and adjusted separately.

3. Investigating the English Content Save Failure

During development, English body content sometimes failed to appear in the saved data even after the post had been saved from the admin interface.

The first step was to check whether HTML sanitization was removing the content during output. Adjusting the allowed HTML settings did not resolve the issue.

Next, the page source and template-level data were inspected. This revealed cases where the English content was not being received during the save process, rather than merely being removed when the page was displayed.

The submitted data was then compared between test cases. With a short test string, the relevant fields were present. With longer English content, however, the body field was missing, and related fields—including the nonce—were also absent in some requests.

The PHP settings on the server were also checked. The main values at the time were:

• post_max_size: 100M
• max_input_vars: 1000
• memory_limit: 300M

These values alone did not establish that the failure was caused by a PHP limit being exceeded.

The WAF logs were also reviewed. Records related to post-editing requests appeared around the times when saving failed, including detection labels such as sqlinj-9.

This suggested that WAF request inspection might have been related to the problem. However, the specific string or data that triggered the detection could not be identified conclusively.

Rather than disabling the WAF for the entire site, the approach to saving the data was reconsidered.

4. Language Switching and Theme Interference

Alongside the save issue, the Japanese-English display system was refined.

The article body was prepared in both languages and connected to the site's existing language-switching feature.

Another issue affected Japanese text containing ruby annotations. Cocoon's table-of-contents processing interfered with the intended output. The relevant processing for Devlog content was adjusted to avoid this unwanted behavior.

Other improvements included display settings in the admin interface and the way draft content was handled.

5. Revising the Save Method and Adding an FTP Fallback

The first alternative was to use the WordPress REST API.

Custom metadata was registered so that settings such as monthly summaries could be managed through the admin interface. This approach worked for some data, including monthly settings and display colors.

However, saving monthly summaries through the admin interface remained unreliable. An alternative using HTML comments in the body was also tested, but it failed as well and was abandoned.

The final approach was to retain the normal WordPress save method as the primary route and add an FTP-managed fallback for the required data.

The system prioritizes data stored by WordPress. If that data is unavailable, it reads the corresponding FTP-managed text file. If neither source contains data, the summary is treated as empty.

Each monthly file stores the Japanese and English monthly summaries in separate sections. For example, the July 2026 file uses the following section names:

• [summary_ja]: Japanese monthly summary
• [summary_en]: English monthly summary

A test confirmed that the July 2026 data could be loaded from FTP.

The admin interface was also updated to indicate whether the summary came from WordPress metadata, an FTP file, or no available data.

This made it possible to manage monthly summaries through FTP when saving them through the admin interface did not work reliably.

6. Improving Related Content

Related-content displays were improved to make it easier for readers to move from Devlog articles to other parts of the site.

For thumbnails, the system checks the featured image first, then the social-sharing image. If neither is available, the link is displayed without a thumbnail.

A preview was added to the admin interface so that related content could be checked before publication. External links were also supported, with URL validation to reject unsafe schemes.

Existing display components were adjusted so that Devlog content could also appear in the site's update and manga-related listings.

7. Background Display and Usability Refinements

The article background was changed from an image stretched to cover the entire area to a repeating background pattern. This helped keep the appearance more consistent across different article lengths and screen sizes.

Further refinements covered article-title and featured-image settings, admin-list ordering, and display names containing ruby annotations.

From related-content previews to URL validation, the improvements focused on making the system easier to use both for editors and for readers.

8. What the Development Process Revealed

One important lesson from this project was that being able to enter content in a form is not the same as successfully sending, saving, and displaying that content. Each stage needed to be checked separately.

By examining PHP settings, submitted data, WordPress save processing, theme output, and WAF logs in sequence, it became possible to narrow down where the problem was occurring. The exact WAF trigger remained unidentified, so the final solution was to provide an alternative data path.

For this site, using FTP-managed data as a fallback also proved useful rather than relying exclusively on WordPress-managed data.

As a result, Devlog evolved from a collection of static pages into a system for managing monthly development records and connecting them with related content across the site.

9. Moving the Public URLs

After the new system was in place, the public Devlog URLs were migrated to match the WordPress structure.

301 redirects were configured for the relevant older article URLs so that visitors could reach the new monthly pages. Indexing requests were also submitted through Google Search Console for the new Devlog landing page and monthly articles.

The goal was not only to change the URLs, but also to preserve access to the new articles from existing links.

Conclusion

From September 28 to October 8, 2026, the project covered the WordPress migration, bilingual display, investigation of save failures, an FTP fallback, and improvements to related content.

A key part of the work was responding to a save failure whose exact cause could not be conclusively identified. By checking logs and submitted data, then combining alternative methods, a practical workaround was implemented.

Devlog records how FUKABORI COLORS is built and how it changes over time. Development records will continue to grow alongside future site updates and new features.