Where v0.0.1 implements a batch search facility we need an admin interface to view the results.

Requirements

• pageable multi-column display of shortcodes that have been discovered
• columns for shortcode, status flags, reference count and content links
• action to display details of references
• sortable by short code name, status and reference count
• action to mark as 'not a shortcode'
• tab to control building/re-building of the schunted data
• checkboxes and other fields to control (re)build processing
• NFRs: security, performance, operability

Proposed solution

• display information using wp_list_table based classes
• multi-tabbed admin page
• extendable to allow other plugins to enhance the information
• satisfy NFRs: security, performance, operability

There are quite a few places where things that might appear to be shortcodes are not actually shortcodes.

• script and CDATA sections
• shortcodes inside shortcodes which don't expand the shortcodes in $content
• inline CSS inside style tags

These should be ignored by the routine that detects shortcodes.
This issue is for the CDATA problem.

Proposed solution

• Use wp_html_split() to split the content
• Ignore <script and <style tags

As noted in #1 there are quite a few places where things that might appear to be shortcodes are not actually shortcodes.

If the content contains CSS enclosed in <style tags then we should ignore this content since the square brackets are more likely to be attribute selectors than shortcodes.

Proposed solution

• Ignore content found within <style tags

Some shortcodes which accept enclosed content will process the content through shortcode expansion. Others don't.

The solution should cater for those shortcodes which don't process what appear to be shortcodes in enclosed content.

Example - enclosed content expanded
[bw_blockquote]Hello [wp][/bw_blockquote]
Expected output

Hello WordPress

Example - enclosed content NOT expanded
[bw_geshi html] Hello [wp][/bw_geshi]

Expected output
Hello [wp]

Requirements

• Search for shortcodes in postmeta data
• Search for shortcodes in options
• Search for shortcodes in serialized data

The original search logic was rather naive and could not handle processing complex serialized data.

It was easy to detect that the content might contain a shortcode but it wasn't doing a very good job of catering for the issues documented in #1, #2 and #3.

It also turns out that some plugins create options and/or post meta data which appear to contain shortcodes but aren't really. e.g. options fields: rewrite_rules, _site_transient_update_plugins, exploitscanner_results

Proposed solution

• Extend the solution to scan postmeta at the same time as scanning posts
• Extend the solution to scan options.
• Support scanning of serialized data

We need to apply the same logic to serialized data as we do to plain text.
To achieve this we need to deserialize the serialized data, and process each nested array recursively.