Configuration constants

• core
  • ~EWIKI_SCRIPT - url creation
• page names
  • EWIKI_PAGE_INDEX
  • EWIKI_PAGE_NEWEST
• rendering
  • EWIKI_RESCUE_HTML
  • EWIKI_HTML_CHARS
• control
  • EWIKI_PROTECTED_MODE
  • EWIKI_IDF_INTERNAL

Current variable categories:

• $ewiki_plugins[]
  • plugins
    • "action"
    • "page"
  • visual
    • "action_view" - which of the "action" plugins is shown as link below each page
  • control
    • "idf"
    • "interwiki"
• Translation
  • $ewiki_t[]
• $GLOBALs
  • generated
    • $ewiki_id
    • $ewiki_action
    • $ewiki_title
    • $ewiki_links
    • $ewiki_data -- apparently set only if *EWIKI_CONTROL_LINE is false when ewiki_control_links is called but ewiki_control_links is not added to plugin array if *EWIKI_CONTROL_LINE is false. I'm confused, can this be set always? Is it perhaps somewhere I didn't notice?
      1. one can see, this one is no longer used, or auto-generated
    • $ewiki_title_action (NEW SUGGESTION)-- a URL to put in the template with the title. -- APF
      1. milky: this needs clearification: what is your URL, what is an template, why needs to be inside of _print_title?
      2. Andy: I call the page that ewiki is embedded in a template or skin do we have a *ProperName for it? $ewiki_title_action(name subject to change) would be the computed url that would go with the title in the print_title method. $ewiki_title and $ewiki_title_action would be a pair and allow for the removal of ewiki_print_title(). This would help with the calendar printer too.
      3. milky: why did this allow to remove _print_title() - then we'd either had no titles or we had to hardcode it into the ewiki_page() call, which would make the titles permanantly present - which was the reason to exlude it from there! I right now added a fifth parameter to specify the action, but a long-term solution would be to create a function to be called also from static and internal page functions (not only real wikipages), but there must be some other changes prior to such an approach (removing *EWIKI_PRINT_TITLE constant in favor of a $_conf variable).
      4. Andy: Oh, I hadn't seen that, I was looking at alternative ways to achieve the goal. I'll have to revisit the concepts to see how this works.
  • externally set ones
    • $ewiki_author
    • $ewiki_ring

milky: some config constants and parts of $ewiki_plugin will go into a new array called $ewiki_config or $ewiki_data or so...?

plugins care themselves about (not core):

• email_protect
  • $_COOKIE[EWIKI_UP_NOSPAMBOT]

Future categories (not core):

• user
  • ???
• location
  • ???
• session
  • = $_USER, $ewiki_plugins["vars"], $_SESSION or $_EWIKI