ewiki info
READMEChangeLog
project site
fm project page
secondary site
|
|
ewiki_ functions()- ewiki_page($id) - ewiki_page_...() - ewiki_control_links($id, $data) - ewiki_format($wiki_source, $params) - ewiki_render_wiki_links(&$o) - ewiki_scan_wikiwords(&$wiki_source, &$ewiki_links) - ewiki_link_regex_callback() - ewiki_script() - ewiki_script_binary() - ewiki_binary() - ewiki_author() - ewiki_auth() - ewiki_auth_user() - ewiki_t() - ewiki_make_title() - ewiki_chunked_page(...) - ewiki_in_array($value, &$array, $dn=0) - ewiki_array($array, $index=false, $am=1) - ewiki_db:: - $ewiki_dbquery_result Some of the core functions of ewiki.php can be used separate from the others and some of them were designed to be replaced by different implementations. Btw, all the functions, constants and variables start with "ewiki_" to make it easier to mix it into other projects (reduces function name conflicts and similar problems, that usually arise if you join two or more scripts into one program). ewiki_page($id) --------------- This is the main function which fetches the selected WikiPage+ (or the one given with $id) via ewiki_database to transform with ewiki_format(). If the requested page does not exist it returns the edit screen. It also includes some virtual pages (InfoAboutThisPage+, NewestPages, SearchPage+, ReferencesToThisPage+, ...). ewiki_page_...() ---------------- These functions were separated out from the main ewiki_page() to make it more readable. Most of them contain code to generate the few special/internal WikiPages+ (Search, Newest, Info, and the Edit <FORM>, ...) ewiki_control_links($id, $data) ------------------------------- Prints the line with the EditThisPage and PageInfo+, ... links. ewiki_format($wiki_source, $params) ---------------------------------------------------------- This returns the formatted (HTML) output for the given WikiSource+ (with all the WikiMarkup in it). The second param is an array with various config overrides. An entry of "scan_links"=>1 for example tells ewiki_format to lookup the referenced WikiPages+ in the database (see ewiki_scan_wikiwords) for filling up $ewiki_links. Another $params entry is "html"=>0, which controls interpetation of the <html>...</html> page content blocks. ewiki_render_wiki_links(&$o) ---------------------------- Transforms WikiLinks+ and square brackets in a page into html links. ewiki_scan_wikiwords(&$wiki_source, &$ewiki_links) -------------------------------------------------- work with regex on the wiki source text, to find valid WikiWords+, the $ewiki_links will be filled with informations if the found page names exist in the DB. ewiki_link_regex_callback() --------------------------- Called from ewiki_format(). To separate the ewiki_format() from the database this function will utilize the global $ewiki_links (generated on demand by ewiki_format) to output either a normal link or a question-mark after the WikiPageName+ to signal a non-existent page. ewiki_script() -------------- Builds the complete URL needed to access the given resource. This function replaces/enhances the static EWIKI_SCRIPT constant and unifies the generated URLs (less bugs). It also helps around various design flaws (like nice looking URL strings), that made some parts of ewiki a bit weird and unreliable in the past. Btw, now the base URL is stored in $ewiki_config["script"]. ewiki_script_binary() --------------------- Is just a ewiki_script() wrapper, but can additionally distinguish between binary download and upload URLs, which could be utilized by (database external) plain file storages (see plugins/binary_store). ewiki_binary() -------------- Gets called automatically for requests with the ?binary= trailer which is used to reference cached and uploaded images (or not yet cached ones). ewiki_author() -------------- returns a string with REMOTE_ADDR and the $ewiki_author or a default string incorporated ewiki_auth() ------------ Is a simple interface to a probably large collection of plugins, which should to actual user and permission management. Support for this in the core is however still sporadic. ewiki_auth_user() ----------------- Queries all registered user databases, and is usually itself called from within an auth_method/auth_query plugin. ewiki_t() --------- Fetches a text string from the $ewiki_t[] array and additionally adds some text pieces into it (given as second param). It can retrieve translations for registered abbreviations, or searches for complete text fragment replacements. It also understands _{...} to recursively translate a text snippet inside of larger text blocks. This is probably a bit slower and less readable than the previous usage of EWIKI_T_+ constants, but it saves some memory and allows to extend translations or additional text constants (of plugins) a lot more easier (previously one had to edit inside a function, which is almost impossible to do from outside / per configuration). ewiki_make_title() ------------------ Returns a string enclosing (the generated) page title (as link) into the html title markup "<h2>". The $class parameter actually tells from which plugin sort it was called, and this decides if a link will be generated or the title will be unclickable plain text (the setting in $ewiki_config["print_title"] is used to determine that). $go_action tells which action to link the title to. ewiki_chunked_page(...) ----------------------- Is a helper function to split large results into multiple click-through pages, and is used by info/ and some search functions/plugins. It only produces the click-through links for inclusion on other dynamic pages, allows overlapping of page chunk ranges. ewiki_in_array($value, &$array, $dn=0) -------------------------------------- Case-insensitive variant of PHPs` in_array(), returns the $value if found. The $array will be all-lowercased afterwards (except when $dn was set). ewiki_array($array, $index=false, $am=1) ---------------------------------------- Returns input-array lowercased (indices), or just the entry for the $index if searched for. The $am decides if multiple entries should be merged together (uppercase+lowercase merging produces overlaps). ewiki_db:: ---------- This static class provides the interface to the database backends. It abstracts the database as a simple flat store for named entries (file or page names). Therefore it is that easy to switch from a SQL backend to a flat file based data store. Actually, this rude form of "database abstraction" has the drawback, that it knows only little about the data it maintains. But this also allows to internally extend the used structures if necessary. You call the individual functions like " ewiki_db::GET() ", the atomic features are: ::GET($id) Fetches the latest version of the "$id" page from the database. ::GET($id, $version) Retrieves a given version instead. Counting starts at 1. ::WRITE($data) Saves the contents of the given data array in the database, does _never_ overwrite an existing entry (you must keep track of the {version} yourself) unless a second paremeter (1) was given. ::GETALL($fieldnames, $mask, $filter) Fetches an array of all existing pages in the database, but returns it as ewiki_dbquery_result object, which will throw the requested columns on ->get(), where the entries 'id', 'version' and 'flags' are always present. ::FIND($list_of_pagenames) Searches the database for the queried page names, returns an array which associates the boolean value (if pages found) with their names ::SEARCH($field, $content, $caseinsensitive, $regex, $mask, $filter) Returns only those pages, where the database COLUMN has a content that matches the requested value; the list of pages is returned as ewiki_dbquery_result object, where you can access the individual entries using the ->get() call, which will return the columns 'id', 'version', 'flags' and the scanned COLUMN of course unless you ->get("_ALL=1"). The following three actions are not required for correct operation, but provide additional functionality for some plugins or tools. ::HIT($id) Increases the hit counter of the given wiki page by 1, what is not implemented in db_flat_file. ::DELETE($id, $version) Removes the specified page (only the given version) from the database; implemented in all database plugins but should be used from within the tools/ only. ::INIT() For SQL database backends this creates the required tables. There are also a few virtual functions, that only provide utility code or make use of the atomic funtions itself: ::APPEND($id, $text) Adds the given $text at the bottom of the named page. ::UPDATE(&$data) Refreshes all the meta data fields in the given page hash, but of the {version} field. This is usefully be called before any ::WRITE call. ::CREATE($id, $flags, $author) Returns a fresh page $data hash. Other functions are usually used internally only, as for example the ->ALLFILES() command in dbff or dba/dbm plugins. $ewiki_dbquery_result --------------------- Has the member variables $keys and $entries, where the latter contains an array of page names that where triggered by your GETALL or SEARCH request, and the $keys array contains the column names that each subsequent "$result->get()" will return. ->get() Returns the database entry array (see GET above), but only the fields the database query should return (at minimum these are 'id', 'version' and 'flags' and the searched column for SEARCH). ->get("_ALL=1") Instead returns the complete entry. ->get(0, $mask) The second parameter is for filtering out content: 0x0001 strips out _HIDDEN pages from the result set 0x0002 removes any _DISABLED pages 0x0020 performs the _PROTECTED_MODE_HIDING checks ->get(0, $mask, $type) if the $type parameter is supplied, then the results are filtered by the given page type (_DB_F_TYPE mask) ->count() Returns the number of found database entries. ->add($row) internal+ This is used by the ewiki_database() core functions to initialize the $result object with the found entries. -------------------------------------------------------------------- 2 --prev << "README.programming" next >> "$GLOBALS pollution ($ewiki_ variables)" You cannot modify the INTERNALS file, but anyhow any ideas or suggestion should as usually get filed on BugReports, UserSuggestions or even better the INTERNALS.Discussion. |