Removing readme text files from code
This commit is contained in:
parent
b461f2b690
commit
3b59d37c3b
54 changed files with 0 additions and 4753 deletions
|
|
@ -1,181 +0,0 @@
|
|||
|
||||
-- SUMMARY --
|
||||
|
||||
The Drupal administration menu module displays the entire administrative
|
||||
menu tree (and most local tasks) in a drop-down menu, providing administrators
|
||||
one- or two-click access to most pages. Other modules may also add menu
|
||||
links to administration menu using hook_admin_menu().
|
||||
|
||||
For a full description of the module, visit the project page:
|
||||
http://drupal.org/project/admin_menu
|
||||
|
||||
To submit bug reports and feature suggestions, or to track changes:
|
||||
http://drupal.org/project/issues/admin_menu
|
||||
|
||||
|
||||
-- REQUIREMENTS --
|
||||
|
||||
None.
|
||||
|
||||
|
||||
-- INSTALLATION --
|
||||
|
||||
* Install as usual, see http://drupal.org/node/70151 for further information.
|
||||
|
||||
|
||||
-- CONFIGURATION --
|
||||
|
||||
* Configure user permissions in Administer >> User management >> Permissions >>
|
||||
admin_menu module:
|
||||
|
||||
- access administration menu
|
||||
|
||||
Users in roles with the "access administration menu" permission will see
|
||||
the administration menu at the top of each page.
|
||||
|
||||
- display drupal links
|
||||
|
||||
Users in roles with the "display drupal links" permission will receive
|
||||
links to Drupal.org issue queues for all enabled contributed modules. The
|
||||
issue queue links appear under the administration menu icon.)
|
||||
|
||||
Note that the menu items displayed in the administration Menu depend on the
|
||||
actual permissions of the viewing user. For example, the "User management"
|
||||
menu item is not displayed to a user who is not a member of a role with the
|
||||
"administer permissions" and "administer users" permissions.
|
||||
|
||||
* Customize the menu settings in Administer >> Site configuration >>
|
||||
Administration menu.
|
||||
|
||||
* To prevent administrative menu items from appearing twice, you may hide the
|
||||
"Navigation" menu block, or move the "Administer" menu items into a separate
|
||||
menu.
|
||||
|
||||
|
||||
-- CUSTOMIZATION --
|
||||
|
||||
* To override the default administration menu icon, you may:
|
||||
|
||||
1) Disable it via CSS in your theme:
|
||||
|
||||
body #admin-menu-icon { display: none; }
|
||||
|
||||
2) Alter the image by overriding the theme function:
|
||||
|
||||
Copy the entire theme_admin_menu_icon() function into your template.php,
|
||||
rename it to phptemplate_admin_menu_icon() or THEMENAME_admin_menu_icon(),
|
||||
and customize the output according to your needs.
|
||||
|
||||
Remember that the output of the administration menu is cached. To see changes
|
||||
from your theme override function, you must clear your site cache (via
|
||||
the "Flush all caches" link on the menu).
|
||||
|
||||
* To override the font size, add the following line to your theme's stylesheet:
|
||||
|
||||
body #admin-menu { font-size: 10px; }
|
||||
|
||||
|
||||
-- TROUBLESHOOTING --
|
||||
|
||||
* If the menu does not display, check the following:
|
||||
|
||||
- Are the "access administration menu" and "access administration pages"
|
||||
permissions enabled for the appropriate roles?
|
||||
|
||||
- Does your theme output the $closure variable?
|
||||
|
||||
* If the menu is rendered behind a Flash movie object, add this property to your
|
||||
Flash object(s):
|
||||
|
||||
<param name="wmode" value="transparent" />
|
||||
|
||||
See http://drupal.org/node/195386 for further information.
|
||||
|
||||
|
||||
-- FAQ --
|
||||
|
||||
Q: When the administration menu module is enabled, blank space is added to the
|
||||
bottom of my theme. Why?
|
||||
|
||||
A: This is caused by a long list of links to module issue queues at Drupal.org.
|
||||
Use Administer >> User management >> Permissions to disable the "display
|
||||
drupal links" permission for all appropriate roles. Note that since UID 1
|
||||
automatically receives all permissions, the list of issue queue links cannot
|
||||
be disabled for UID 1.
|
||||
|
||||
|
||||
Q: After upgrading to 6.x-1.x, the menu disappeared. Why?
|
||||
|
||||
A: You may need to regenerate your menu. Visit
|
||||
http://example.com/admin/build/modules to regenerate your menu (substitute
|
||||
your site name for example.com).
|
||||
|
||||
|
||||
Q: Can I configure the administration menu module to display another menu (like
|
||||
the Navigation menu, for instance)?
|
||||
|
||||
A: No. As the name implies, administration menu module is for administrative
|
||||
menu links only. However, you can copy and paste the contents of
|
||||
admin_menu.css into your theme's stylesheet and replace #admin-menu with any
|
||||
other menu block id (#block-menu-1, for example).
|
||||
|
||||
|
||||
Q: Sometimes, the user counter displays a lot of anonymous users, but no spike
|
||||
of users or requests appear in Google Analytics or other tracking tools.
|
||||
|
||||
A: If your site was concurrently spidered by search-engine robots, it may have
|
||||
a significant number of anonymous users for a short time. Most web tracking
|
||||
tools like Google Analytics automatically filter out these requests.
|
||||
|
||||
|
||||
Q: I enabled "Aggregate and compress CSS files", but admin_menu.css is still
|
||||
there. Is this normal?
|
||||
|
||||
A: Yes, this is the intended behavior. the administration menu module only loads
|
||||
its stylesheet as needed (i.e., on page requests by logged-on, administrative
|
||||
users).
|
||||
|
||||
|
||||
Q: Why are sub-menus not visible in Opera?
|
||||
|
||||
A: In the Opera browser preferences under "web pages" there is an option to fit
|
||||
to width. By disabling this option, sub-menus in the administration menu
|
||||
should appear.
|
||||
|
||||
|
||||
Q: How can the administration menu be hidden on certain pages?
|
||||
|
||||
A: You can suppress it by simply calling the following function in PHP:
|
||||
|
||||
module_invoke('admin_menu', 'suppress');
|
||||
|
||||
However, this needs to happen as early as possible in the page request, so
|
||||
placing it in the theming layer (resp. a page template file) is too late.
|
||||
Ideally, the function is called in hook_init() in a custom module. If you do
|
||||
not have a custom module, placing it into some conditional code at the top of
|
||||
template.php may work out, too.
|
||||
|
||||
|
||||
-- CONTACT --
|
||||
|
||||
Current maintainers:
|
||||
* Daniel F. Kudwien (sun) - http://drupal.org/user/54136
|
||||
* Peter Wolanin (pwolanin) - http://drupal.org/user/49851
|
||||
* Stefan M. Kudwien (smk-ka) - http://drupal.org/user/48898
|
||||
* Dave Reid (Dave Reid) - http://drupal.org/user/53892
|
||||
|
||||
Major rewrite for Drupal 6 by Peter Wolanin (pwolanin).
|
||||
|
||||
This project has been sponsored by:
|
||||
* UNLEASHED MIND
|
||||
Specialized in consulting and planning of Drupal powered sites, UNLEASHED
|
||||
MIND offers installation, development, theming, customization, and hosting
|
||||
to get you started. Visit http://www.unleashedmind.com for more information.
|
||||
|
||||
* Lullabot
|
||||
Friendly Drupal experts providing professional consulting & education
|
||||
services. Visit http://www.lullabot.com for more information.
|
||||
|
||||
* Acquia
|
||||
Commercially Supported Drupal. Visit http://acquia.com for more information.
|
||||
|
||||
|
|
@ -1,372 +0,0 @@
|
|||
|
||||
----------------------------------
|
||||
ADVANCED CSS/JS AGGREGATION MODULE
|
||||
----------------------------------
|
||||
|
||||
|
||||
CONTENTS OF THIS FILE
|
||||
---------------------
|
||||
|
||||
* Fast 404
|
||||
* Features & benefits
|
||||
* Configuration
|
||||
* Notes
|
||||
* JavaScript Bookmarklet
|
||||
* Technical Details & Hooks
|
||||
* Single htaccess rules
|
||||
* nginx Configuration
|
||||
|
||||
|
||||
FAST 404
|
||||
--------
|
||||
|
||||
Assuming that this guide was followed:
|
||||
http://2bits.com/drupal-planet/reducing-server-resource-utilization-busy-sites-implementing-fast-404s-drupal.html
|
||||
and your having issues with Advanced CSS/JS Aggregation. Advagg works similar
|
||||
to imagecache, thus we need to add in an exceptions for the directories that
|
||||
advagg uses. Replace this if statement
|
||||
|
||||
if (!strpos($_SERVER['QUERY_STRING'], 'imagecache')) {
|
||||
|
||||
with one like this:
|
||||
|
||||
if (!strpos($_SERVER['QUERY_STRING'], 'imagecache') && !strpos($_SERVER['QUERY_STRING'], '/advagg_')) {
|
||||
|
||||
This will most likely be in your settings.php file.
|
||||
|
||||
If using Nginx make sure there is a rule similar to this in your configuration.
|
||||
http://drupal.org/node/1116618#comment-4321724
|
||||
|
||||
If this is still an issue you can try setting the
|
||||
"IP Address to send all asynchronous requests to" setting on the
|
||||
admin/settings/advagg/config page to -1. This will use the hostname instead of
|
||||
an IP address when making the http request.
|
||||
|
||||
If you are still having problems, open an issue on the advagg issue queue:
|
||||
http://drupal.org/project/issues/advagg
|
||||
|
||||
|
||||
FEATURES & BENEFITS
|
||||
-------------------
|
||||
|
||||
Advanced CSS/JS Aggregation Core Module:
|
||||
* Imagecache style CSS/JS Aggregation. If the file doesn't exist it will be
|
||||
generated on demand.
|
||||
* Stampede protection for CSS and JS aggregation. Uses locking so multiple
|
||||
requests for the same thing will result in only one thread doing the work.
|
||||
* Zero file I/O if the Aggregated file already exists. Results in better page
|
||||
generation performance.
|
||||
* Fully cached CSS/JS assets making this module faster than drupal core.
|
||||
* Smarter aggregate deletion. CSS/JS aggregates only get removed from the cache
|
||||
if they have not been used/accessed in the last 3 days.
|
||||
* Smarter cache flushing. Scans all CSS/JS files that have been added to any
|
||||
aggregate; if that file has changed then rebuild all aggregates that contain
|
||||
the updated file and give the newly aggregated file a new name. The new name
|
||||
ensures changes go out when using CDNs.
|
||||
* Works with Drupal's private file system. Can Use a separate directory for
|
||||
serving aggregated files from.
|
||||
* Footer JS gets aggregated as well.
|
||||
* One can add JS to any region & have it aggregated.
|
||||
drupal_add_js($data, 'module', 'left') is now possible; JS is appended to the
|
||||
the end of that region.
|
||||
* One can add external JS/CSS resources.
|
||||
drupal_add_js('http://example.org/example.js', 'external');
|
||||
drupal_add_css('http://example.org/example.css', 'external');
|
||||
is now possible.
|
||||
* Url query string to turn off aggregation for that request. ?advagg=0 will
|
||||
turn off file aggregation if the user has the "bypass advanced aggregation"
|
||||
permission. ?advagg=-1 will completely bypass all of Advanced CSS/JS
|
||||
Aggregations modules and submodules.
|
||||
* Button on the admin page for dropping a cookie that will turn off file
|
||||
aggregation. Useful for theme development.
|
||||
* Url query string to turn on advagg debugging for that request.
|
||||
?advagg-debug=1 will output a large debug string to the watchdog if the user
|
||||
has the "bypass advanced aggregation" permission.
|
||||
* Gzip support. All aggregated files can be pre-compressed into a .gz file and
|
||||
served from Apache. This is faster then gzipping the file on each request.
|
||||
* IE Unlimited CSS support. If using ?advagg=0 the CSS output will change
|
||||
to use @import style in order to get around the 31 CSS files limit in IE.
|
||||
* CDN support. Advagg integrates with this module.
|
||||
* jQuery Update support. Advagg integrates with this module.
|
||||
* LABjs support. Advagg integrates with this module.
|
||||
* One year browser cache lifetimes for all aggregated files. This is a good
|
||||
thing.
|
||||
* Drush support. "cc advagg" will issue a smart cache flush.
|
||||
* Admin menu support. Cache flushing Advanced CSS/JS Aggregation is available
|
||||
in the "Flush all caches" menu.
|
||||
|
||||
Advanced CSS/JS Aggregation Submodules:
|
||||
CSS:
|
||||
* CSSTidy library support. Can compress the generated CSS files with the
|
||||
CSSTidy library.
|
||||
* CSS Compressor 3.0 support. https://github.com/codenothing/css-compressor
|
||||
JS:
|
||||
* JSMin+ library support. Can compress the generated JS files with the jsmin+
|
||||
library.
|
||||
* JSMin PHP Extension support. http://www.ypass.net/software/php_jsmin/
|
||||
* Use Dean Edwards Packer on non gzipped files. .gz files will not be packed.
|
||||
CDN:
|
||||
* Google's CDN network. Load jquery.js & jquery-ui.js from using the Google
|
||||
Libraries API. This is a good thing.
|
||||
Bundler:
|
||||
* Bundler. Will split up an aggregate into sub aggregates for better load
|
||||
times throughout your site.
|
||||
|
||||
3rd Party modules:
|
||||
CSS:
|
||||
* Parallel CSS - AdvAgg Plugin. Have url()'s in css files reference different
|
||||
CDN domains.
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
Settings page is located at:
|
||||
admin/settings/advagg
|
||||
* Enable Advanced Aggregation. You can disable the module here. Same effect as
|
||||
placing ?advagg=-1 in the URL.
|
||||
* Use AdvAgg in closure. If enabled javascript files in the closure region will
|
||||
be aggregated by advagg.
|
||||
* Generate CSS/JS files on request (async mode). If advagg doesn't have a route
|
||||
back to its self and this is enabled then you will have a broken site. With
|
||||
this enabled one can expect much quicker page generation times after a cache
|
||||
flush.
|
||||
* Gzip CSS/JS files. For every Aggregated file generated, this will create a
|
||||
gzip version of that and then serve that out if the browser accepts gzip
|
||||
compression.
|
||||
* Generate .htaccess files in the advagg_* dirs. If your using the rules
|
||||
located at the bottom of this document in your webroots htaccess file then
|
||||
you can disable this checkbox.
|
||||
* Regenerate flushed bundles in the cache flush request. You can enable if your
|
||||
server will not timeout on a request. This will call advagg_rebuild_bundle()
|
||||
as a shutdown function for every bundle that has been marked as expired;
|
||||
thus rebuilding that bundle in the same request as the flush.
|
||||
* Use a different directory for storing advagg files. Only available if your
|
||||
using a private file system. Allows you to save the generated aggregated
|
||||
files in a different directory. This gets around the private file system
|
||||
restrictions. If boost is installed, you can safely use the cache directory.
|
||||
* Aggregation Inclusion Mode. Should the page wait for the aggregate to be
|
||||
built before including the file, or should it send out the page with
|
||||
aggregates not included.
|
||||
* Disable page caching if all aggregates are not included on the page.
|
||||
* File Checksum Mode. mtime is the file modification time. md5 is a hash of the
|
||||
files contents.
|
||||
* IP Address to send all asynchronous requests to. If you wish to have one
|
||||
server generate all CSS/JS aggregated files then this allows for that to
|
||||
happen.
|
||||
* Smart cache flush button. Scan all files referenced in aggregated files. If any of
|
||||
them have changed, increment the counters containing that file and rebuild
|
||||
the bundle.
|
||||
* Cache Rebuild button. Recreate all aggregated files. Useful if JS or CSS
|
||||
compression was just enabled.
|
||||
* Forced Cache Rebuild. Recreate all aggregated files by incrementing internal
|
||||
counter for every bundle. One should never have to use this option.
|
||||
* Master Reset. Clean slate; same affect as uninstalling the module.
|
||||
* Rebuild htaccess files. Recreate the generated htaccess files.
|
||||
* Aggregation Bypass Cookie. This will set or remove a cookie that disables
|
||||
aggregation for the remainder of the browser session. It acts almost the same
|
||||
as adding ?advagg=0 to every URL.
|
||||
|
||||
Additional information is available at:
|
||||
admin/settings/advagg/info
|
||||
* Hook Theme Info. Displays the preprocess_page order. Used for debugging.
|
||||
* CSS files. Displays how often a files checksum has changed and any data
|
||||
stored about it.
|
||||
* JS files. Displays how often a files checksum has changed and any data
|
||||
stored about it.
|
||||
* Modules implementing advagg hooks. Lets you know what modules are using
|
||||
advagg.
|
||||
* Missing files. Lets you know the files that are trying to be added but are
|
||||
not there.
|
||||
* Asynchronous debug info. Outputs the the full object returned from
|
||||
drupal_http_request() which is helpful when debugging async issues.
|
||||
|
||||
|
||||
NOTES
|
||||
-----
|
||||
|
||||
--Bundler Sub Module--
|
||||
When using the bundler sub module, tools like Google Page Speed and YSlow will
|
||||
complain that not all CSS/JS files are in one aggregate. This has to do with
|
||||
how drupal_add_js/drupal_add_css works. You can get a better score on these
|
||||
tools by placing all files into one aggregate, but the issue with doing that
|
||||
is, different pages load different css/js files, thus on page 2 of the users
|
||||
visit, you will get worse performance because the browser has to re-download a
|
||||
whole new css & js aggregate rather then the smaller aggregate that only
|
||||
changed. The bundler attempts to work around this issue by creating various
|
||||
bundles, each one being chosen fairly smartly so that instead of downloading a
|
||||
200KB js file you only have to download a 20KB file on the 2nd page.
|
||||
|
||||
The bundler sub module is all about balancing trade offs. You can make a site
|
||||
that had really good performance stats according to the tools but you would
|
||||
then have to re-download just about everything on a different page of your
|
||||
site, because not all your pages are the same. If you don't care about this and
|
||||
want a good score from pagespeed, disable the bundler sub-module. That will
|
||||
give you a better score, but then you have to download a new (large) aggregate
|
||||
on different parts of your website and already downloaded file reuse will be
|
||||
lower.
|
||||
|
||||
--Cron--
|
||||
The cron job for AdvAgg is there as a garbage collector. It only needs to run
|
||||
once a week; running it every hour isn't going to be bad, it isn't necessary
|
||||
though.
|
||||
|
||||
|
||||
JAVASCRIPT BOOKMARKLET
|
||||
----------------------
|
||||
|
||||
You can use this JS code as a bookmarklet for toggling the AdvAgg URL parameter.
|
||||
See http://en.wikipedia.org/wiki/Bookmarklet for more details.
|
||||
|
||||
javascript:(function(){var loc = document.location.href,qs = document.location.search,regex_off = /\&?advagg=-1/,goto = loc;if(qs.match(regex_off)) {goto = loc.replace(regex_off, '');} else {qs = qs ? qs + '&advagg=-1' : '?advagg=-1';goto = document.location.pathname + qs;}window.location = goto;})();
|
||||
|
||||
|
||||
TECHNICAL DETAILS & HOOKS
|
||||
-------------------------
|
||||
|
||||
Technical Details:
|
||||
* There are two database tables and two cache table used by advagg.
|
||||
* Files are generated by this pattern: css_[MD5]_[Counter].css
|
||||
* Every JS file is tested for compressibility. This is necessary because jsmin+
|
||||
can run out of memory on certain files. This allows us to catch these bad
|
||||
files and mark them. Also allows us to skip files that are already
|
||||
compressed.
|
||||
|
||||
Hooks:
|
||||
* hook_advagg_css_alter. Modify the data before it gets written to the file.
|
||||
Useful for compression.
|
||||
* hook_advagg_css_inline_alter. Modify the data before it gets embedded in the
|
||||
page. Useful for compression.
|
||||
* hook_advagg_css_pre_alter. Modify the raw $variables['css'] before it gets
|
||||
processed. Useful for file replacement.
|
||||
* hook_advagg_css_extra_alter. Allows one to set the a prefix and suffix to be
|
||||
added into the HTML DOM. Useful for CSS conditionals.
|
||||
|
||||
* hook_advagg_js_alter. Modify the data before it gets written to the file.
|
||||
Useful for compression.
|
||||
* hook_advagg_js_inline_alter. Modify the data before it gets embedded in the
|
||||
page. Useful for compression.
|
||||
* hook_advagg_js_pre_alter. Modify the raw $javascript before it gets
|
||||
processed. Useful for file replacement.
|
||||
* hook_advagg_js_extra_alter. Allows one to set the a prefix and suffix to be
|
||||
added into the HTML DOM.
|
||||
* hook_advagg_js_header_footer_alter. Allows one to move JS from the header to
|
||||
the footer. Also one can look at both header and footer JS arrays before they
|
||||
get processed.
|
||||
|
||||
* hook_advagg_filenames_alter. Allows for a one to many relationship. A single
|
||||
request for a bundle name can result in multiple bundles being returned.
|
||||
* hook_advagg_files_table. Allows for modules to mark a file as expired.
|
||||
* advagg_master_reset. Allows other modules to take part in a master reset.
|
||||
* advagg_disable_processor. Allows one to turn off advagg from a hook. See the
|
||||
advagg_advagg_disable_processor() function for example usage.
|
||||
* advagg_disable_page_cache. Allows 3rd party page cache plugins like boost or
|
||||
varnish to not cache this page.
|
||||
* advagg_bundler_analysis_alter. Give installed modules a chance to alter the
|
||||
bundler's analysis array.
|
||||
|
||||
JS/CSS Theme Override:
|
||||
|
||||
$conf['advagg_css_render_function'] - advagg_unlimited_css_builder
|
||||
$conf['advagg_js_render_function'] - advagg_js_builder
|
||||
|
||||
JS/CSS File Save Override:
|
||||
|
||||
$conf['advagg_file_save_function'] - advagg_file_saver
|
||||
|
||||
Public Functions:
|
||||
* advagg_add_css_inline. Adds the ability to add in inline CSS to the page with
|
||||
a prefix and suffix being set as well.
|
||||
|
||||
|
||||
SINGLE HTACCESS RULES
|
||||
---------------------
|
||||
|
||||
If the directory level htaccess rules are interfering with your server, you can
|
||||
place these rules in the Drupal root htaccess file. Place these rules after
|
||||
"RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]" but before "</IfModule>"
|
||||
|
||||
|
||||
# Rules to correctly serve gzip compressed CSS and JS files.
|
||||
# Requires both mod_rewrite and mod_headers to be enabled.
|
||||
<IfModule mod_headers.c>
|
||||
# Serve gzip compressed CSS/JS files if they exist and client accepts gzip.
|
||||
RewriteCond %{HTTP:Accept-encoding} gzip
|
||||
RewriteCond %{REQUEST_URI} (^/(.+)/advagg_(j|cs)s/(.+)\.(j|cs)s) [NC]
|
||||
RewriteCond %{REQUEST_FILENAME}\.gz -s
|
||||
RewriteRule ^(.*)\.(j|cs)s$ $1\.$2s\.gz [QSA]
|
||||
|
||||
# Serve correct content types, and prevent mod_deflate double gzip.
|
||||
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
|
||||
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
|
||||
|
||||
<FilesMatch "\.(j|cs)s\.gz$">
|
||||
# Serve correct encoding type.
|
||||
Header set Content-Encoding gzip
|
||||
# Force proxies to cache gzipped & non-gzipped css/js files separately.
|
||||
Header append Vary Accept-Encoding
|
||||
</FilesMatch>
|
||||
</IfModule>
|
||||
|
||||
|
||||
You also need to place these rules at the very end of your htaccess file, after
|
||||
"</IfModule>".
|
||||
|
||||
|
||||
# AdvAgg Rules Start.
|
||||
<FilesMatch "^(j|cs)s_[0-9a-f]{32}_.+\.(j|cs)s(\.gz)?">
|
||||
# No mod_headers
|
||||
<IfModule !mod_headers.c>
|
||||
# No mod_expires
|
||||
<IfModule !mod_expires.c>
|
||||
# Use ETags.
|
||||
FileETag MTime Size
|
||||
</IfModule>
|
||||
|
||||
# Use Expires Directive.
|
||||
<IfModule mod_expires.c>
|
||||
# Do not use ETags.
|
||||
FileETag None
|
||||
# Enable expirations.
|
||||
ExpiresActive On
|
||||
# Cache all aggregated CSS/JS files for 480 weeks after access (A).
|
||||
ExpiresDefault A290304000
|
||||
</IfModule>
|
||||
</IfModule>
|
||||
|
||||
<IfModule mod_headers.c>
|
||||
# Set a far future Cache-Control header to 480 weeks.
|
||||
Header set Cache-Control "max-age=290304000, no-transform, public"
|
||||
# Set a far future Expires header.
|
||||
Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT"
|
||||
# Pretend the file was last modified a long time ago in the past.
|
||||
Header set Last-Modified "Wed, 20 Jan 1988 04:20:42 GMT"
|
||||
# Do not use etags for cache validation.
|
||||
Header unset ETag
|
||||
</IfModule>
|
||||
</FilesMatch>
|
||||
# AdvAgg Rules End.
|
||||
|
||||
|
||||
Be sure to disable the "Generate .htaccess files in the advagg_* dirs" setting
|
||||
on the admin/settings/advagg page after placing these rules in the webroots
|
||||
htaccess file. This is located at the same directory level as Drupal's
|
||||
index.php.
|
||||
|
||||
|
||||
NGINX CONFIGURATION
|
||||
-------------------
|
||||
|
||||
http://drupal.org/node/1116618
|
||||
|
||||
###
|
||||
### advagg_css and advagg_js support
|
||||
###
|
||||
location ~* files/advagg_(?:css|js)/ {
|
||||
access_log off;
|
||||
gzip_static on;
|
||||
expires max;
|
||||
add_header ETag "";
|
||||
add_header Cache-Control "max-age=31449600, no-transform, public";
|
||||
try_files $uri @drupal;
|
||||
}
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
||||
;; Autocomplete Widgets for CCK Text and Number fields
|
||||
;;
|
||||
;; Module Author: markus_petrux (http://drupal.org/user/39593)
|
||||
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
||||
|
||||
OVERVIEW
|
||||
========
|
||||
|
||||
This module adds 2 autocomplete widgets for CCK fields.
|
||||
|
||||
- Autocomplete for allowed values list: This widget can be used for Text and
|
||||
Number fields and it takes candidate values from the defined list of Allowed
|
||||
values of the fields.
|
||||
|
||||
- Autocomplete for existing field data: This widget can be used for Text only
|
||||
and it takes candidate values from existing values in the database for that
|
||||
field.
|
||||
|
||||
Both widgets allow you to choose the size of the text element and the method
|
||||
used to match values between 'Starts with' and 'Contains'.
|
||||
|
||||
When the Internationalization module [1] is enabled, the 'Autocomplete for
|
||||
existing field data' widget also provides an option to filter values by the
|
||||
language assigned to their corresponding nodes. This option allows you to
|
||||
provide a different set of allowed values per language.
|
||||
|
||||
[1] http://drupal.org/project/i18n
|
||||
|
||||
|
||||
REQUIREMENTS
|
||||
============
|
||||
|
||||
- CCK (http://drupal.org/project/cck)
|
||||
- CCK Text and/or Number modules provided by CCK itself.
|
||||
|
||||
|
||||
INSTALLATION
|
||||
============
|
||||
|
||||
- Copy all contents of this package to your modules directory preserving
|
||||
subdirectory structure.
|
||||
|
||||
- Goto Administer > Site building > Modules to install this module.
|
||||
|
||||
- Create or edit content types and start using the widgets for your Text and/or
|
||||
Number fields. :)
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
DESCRIPTION
|
||||
===========
|
||||
The Autosave module automatically saves a node after a period of time. Content types that can be autosaved as well as the
|
||||
period of time a node is autosaved, is configurable.
|
||||
|
||||
Autosaved nodes are are saved as a snap shot of the form.
|
||||
|
||||
NOTE: this version of autosave only works for single form (of selected node type) on a page.
|
||||
|
||||
|
||||
DEPENDENCIES
|
||||
============
|
||||
Includes the jQuery Form Plugin which was downloaded from here: http://dev.jquery.com/browser/trunk/plugins/form/jquery.form.js?format=txt
|
||||
|
||||
NOTE: the plugin has been modified to work with Drupal field names
|
||||
|
||||
INSTALLATION
|
||||
============
|
||||
1. Place the "autosave" folder in your "modules" directory (i.e. modules/autosave).
|
||||
2. Enable the Autosave module under Administer >> Site building >> Modules.
|
||||
3. Under config for a node type select it to use Autosave.
|
||||
5. Under Admin -> Site Config -> Autosave enter the period of time before each autosave (in milliseconds).
|
||||
|
||||
AUTHOR
|
||||
======
|
||||
original concept by Edmund Kwok (edmund.kwok [at] insyghtful.com)
|
||||
Drupal 6 version and current maintainer: Peter Lindstrom of LiquidCMS
|
||||
|
||||
CHANGE LOG
|
||||
==========
|
||||
- 6.x-2.0 version is a complete re-write to remove dependencies on TinyMCE.
|
||||
- this version is now tied to the WYSIWYG module and currently is known to work with FCK, CK and TinyMCE 3.0 editors but requires
|
||||
the 6.x-2.x-dev version of WYSIWYG with this patch: http://drupal.org/node/614146#comment-2193764; this patch should be commited soon and will
|
||||
eventually be expanded to include other editors.
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
Better formats is a module to add more flexibility to Drupal's core input format system.
|
||||
Features
|
||||
|
||||
* Set the default format per role.
|
||||
* Set the default format per content type.
|
||||
* Control allowed formats per content type.
|
||||
* Hide format tips.
|
||||
* Hide format selection, forcing the default to be used.
|
||||
* Expand the selection fieldset by default.
|
||||
* Disable the expand/collapse of the selection fieldset.
|
||||
* Set selection fieldset title.
|
||||
* Set default formats for nodes, comments, and blocks separately.
|
||||
* Works with CCK textareas.
|
||||
* Panels comment support.
|
||||
* I18n module support.
|
||||
* and more.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Installation:
|
||||
|
||||
1. Copy the module folder to your server.
|
||||
2. Enable the module via the modules page.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Simple 4-step usage:
|
||||
|
||||
1. Go to user permissions (/admin/user/permissions) and set your permissions.
|
||||
2. Navigate to Site Configuration > Input formats (/admin/settings/filters)
|
||||
3. There you will find 2 tabs where you can change your settings.
|
||||
Defaults (/admin/settings/filters/defauts)
|
||||
Settings (/admin/settings/filters/settings)
|
||||
4. If you enable the "Control formats per node type" option. Go to your content
|
||||
type admin page to set those settings (example /admin/content/node-type/page).
|
||||
The settings are under the Input format settings fieldset.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Important:
|
||||
|
||||
When setting default formats ensure that you arranged the roles correctly
|
||||
placing roles in their order of precedence. This is used to determine what
|
||||
default a user will get when they have more than 1 role.
|
||||
|
||||
NOTE:
|
||||
All logged in users are automatically assigned the authenticated user role
|
||||
so this role must be below all other roles that you want to set a default for or
|
||||
they will get the authenticated user role default instead.
|
||||
|
||||
Example:
|
||||
Let's say you have the 2 roles that come with Drupal and have added an
|
||||
'admin' role. You would most likely want to arrange the roles in this order:
|
||||
|
||||
admin
|
||||
authenticated user
|
||||
anonymous user
|
||||
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Extended usage and notes:
|
||||
|
||||
* The default format will only be set on NEW nodes and comments. The format
|
||||
selected when the form is submitted is used for future editing purposes.
|
||||
|
||||
* The module is designed to always fall back to default settings when needed.
|
||||
This means that when you enable the module before you change any settings,
|
||||
it will use your current Drupal settings. Also when you enable conrol per node
|
||||
type it will use your global settings until you save the content type with new
|
||||
settings.
|
||||
|
||||
* The permissions "collapse format fieldset by default" and
|
||||
"collapsible format selection" will only work if "Show format selection" is
|
||||
also given. This is because those 2 perms only have an effect when there is
|
||||
a format selection.
|
||||
|
||||
* The permission "collapse format fieldset by default" will only work if
|
||||
"collapsible format selection" is also given. This is because the
|
||||
fieldset can only be collapsed by default if it is collapsible.
|
||||
|
||||
* If you dis-allow a format that is already being used by content, the module
|
||||
will do its best to set the correct format. The precidence of the formats are:
|
||||
1. Existing format selected when last saved
|
||||
2. Content type default format
|
||||
3. Global default format
|
||||
4. First allowed format
|
||||
5. Drupal core site default format
|
||||
|
||||
* User 1 is treated the same as all other users when it comes to a default
|
||||
format. If user 1 has not been assigned any roles then it will be assigned
|
||||
the authenticated user role's default format. If you want user 1 to have the
|
||||
default of another role assign that role to user 1.
|
||||
|
||||
* Ensure you read the important notes in the previous section marked important.
|
||||
It explains how you must order your roles to effectively get your defaults.
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
= Installation =
|
||||
|
||||
# Extract du zip file in the modules directory
|
||||
# Enable the module in the admin settings
|
||||
|
||||
= Configuration =
|
||||
|
||||
# Go to Book Made Simple settings and :
|
||||
- Select content types that will populate the child drop down list in book links.
|
||||
- Select content types to auto create main book page when creating.
|
||||
# Or edit a content type and check or uncheck Auto create book main page and Allow content type as child of book
|
||||
|
||||
= Use =
|
||||
|
||||
This module will create a main book page for content type selected in BookMadeSimple settings. This is a shortcut to create a node and click on Update book outline.
|
||||
|
||||
A dropdown listbox will be add in books links. Selecting a content type will add it as a child page of the book page.
|
||||
|
||||
= Tips =
|
||||
|
||||
To hide standard Add child page on links, add this line in your css file :
|
||||
|
||||
li.book_add_child a{display:none;}
|
||||
|
||||
To place dropdown listbox top of links, add this lines in your template.php file :
|
||||
|
||||
function <your template>_links($links, $attributes = array('class' => 'links')) {
|
||||
if (array_key_exists("book_made_simple",$links)) {
|
||||
$a = $links["book_made_simple"];
|
||||
unset($links["book_made_simple"]);
|
||||
array_unshift($links,$a);
|
||||
}
|
||||
return theme_links($links, $attributes = array('class' => 'links'));
|
||||
}
|
||||
|
||||
= Permissions =
|
||||
BMS has two user permissions :
|
||||
|
||||
# Show reoder book link : Visibility of the Reorder book link
|
||||
# Hide core outline links : Hide or show the core outline links of the book module.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Just some credits.
|
||||
|
||||
The throbber is from thickbox and the x is from a jquery tooltip library, although I cannot remember which.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
Creates calendar displays of Views results.
|
||||
|
||||
Create a new calendar by enabling or cloning the default calendar,
|
||||
changing the date argument to use the correct date field(s), and setting
|
||||
up the year, month, day, week, and block views with the desired styles
|
||||
and fields.
|
||||
|
||||
Unlike previous versions of the Calendar module, there is just a single
|
||||
Date argument instead of year, month, and day arguments. The argument
|
||||
value will be YYYY-MM-DD for a day, YYYY-MM for a month, YYYY for a
|
||||
year, and YYYY-W99 for a week. There is a default option to set the
|
||||
argument to the current date when the argument is empty.
|
||||
|
||||
A calendar display creates calendar navigation and links to
|
||||
multiple displays for the year, month, day, or week views. The actual
|
||||
displays are created by attaching calendar views that use whatever
|
||||
styles are desired for those pages.
|
||||
|
||||
Calendar views are attachments to create the year, month, day,
|
||||
and week displays. They can be set to use any style, either a
|
||||
calendar style or any other Views style, like teasers or lists.
|
||||
If you don't want to use one of them, don't attach it to
|
||||
anything. Only the attached views will show up in the calendar.
|
||||
|
||||
A calendar block will create a calendar block for the
|
||||
view results. Attach a block view to the block and set up the
|
||||
desired style in the block view.
|
||||
|
||||
If the Calendar iCal module is enabled, an iCal feed can be
|
||||
attached to the view.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
|
||||
Content Construction Kit
|
||||
------------------------
|
||||
|
||||
NOTE: Install the advanced_help module (http://drupal.org/project/advanced_help)
|
||||
to access more help (writing still in progress...)
|
||||
|
||||
To install, place the entire CCK folder into your modules directory.
|
||||
Go to Administer -> Site building -> Modules and enable the Content module and one or
|
||||
more field type modules:
|
||||
|
||||
- text.module
|
||||
- number.module
|
||||
- userreference.module
|
||||
- nodereference.module
|
||||
|
||||
Now go to Administer -> Content management -> Content types. Create a new
|
||||
content type and edit it to add some fields. Then test by creating
|
||||
a new node of your new type using the Create content menu link.
|
||||
|
||||
The included optionswidget.module provides radio and check box selectors
|
||||
for the various field types.
|
||||
|
||||
The included fieldgroup.module allows you to group fields together
|
||||
in fieldsets to help organize them.
|
||||
|
||||
A comprehensive guide to using CCK is available as a CCK Handbook
|
||||
at http://drupal.org/node/101723.
|
||||
|
||||
Known incompatibilitie
|
||||
----------------------
|
||||
|
||||
The Devel Themer module that ships with Devel is known to mess with CCK admin pages.
|
||||
As a general rule, Devel Themer should only be switched on intermittently when doing
|
||||
theme work on a specific page, and switched off immediately after that, for it adds
|
||||
massive processing overhead.
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
The Content Construction Kit was originally developped by:
|
||||
John Van Dyk
|
||||
Jonathan Chaffer
|
||||
|
||||
Current maintainers:
|
||||
Karen Stevenson
|
||||
Yves Chedemois
|
||||
|
||||
|
|
@ -1,99 +0,0 @@
|
|||
|
||||
CONTENTS OF THIS FILE
|
||||
=====================
|
||||
- USING MULTIGROUPS
|
||||
- FIELDS AND WIDGETS THAT WORK IN MULTIGROUPS
|
||||
- VIEWS INTEGRATION
|
||||
- TROUBLESHOOTING
|
||||
|
||||
|
||||
USING MULTIGROUPS
|
||||
=================
|
||||
|
||||
The Multigroup group treats all included fields like a single field, keeping
|
||||
the related delta values of all included fields synchronized.
|
||||
|
||||
To use a Multigroup, create a new group, make it the 'Multigroup' type, set
|
||||
the number of multiple values for all the fields in the Multigroup, and drag
|
||||
into it the fields that should be included.
|
||||
|
||||
All fields in the Multigroup will automatically get the group setting for
|
||||
multiple values. On the node form, the group is rearranged to keep the delta
|
||||
values for each field in a single drag 'n drop group, by transposing the
|
||||
normal array(group_name => field_name => delta => value) into
|
||||
array(group_name => delta => field_name => value).
|
||||
|
||||
During validation and submission, the field values are restored to their
|
||||
normal positions.
|
||||
|
||||
|
||||
FIELDS AND WIDGETS THAT WORK IN MULTIGROUPS
|
||||
===========================================
|
||||
|
||||
All fields that allow the Content module to handle their multiple values should
|
||||
work here. Fields that handle their own multiple values will not be allowed
|
||||
into Multigroups unless they implement hook_content_multigroup_allowed_widgets()
|
||||
to add their widgets to the allowed widget list. Example:
|
||||
|
||||
@code
|
||||
function MODULE_content_multigroup_allowed_widgets() {
|
||||
return array('WIDGET_NAME_1', 'WIDGET_NAME_2', ...);
|
||||
}
|
||||
@endcode
|
||||
|
||||
All fields that allow the Content module to handle their multiple values
|
||||
should work correctly when a field placed on a Multigroup is moved off, to a
|
||||
normal field group, or to the top level of the form. Fields that handle their
|
||||
own multiple values which may store different results in Multigroup and
|
||||
standard groups should implement hook_content_multigroup_no_remove_widgets()
|
||||
to add their widgets to the list of widgets that cannot be removed from
|
||||
Multigroups. Example:
|
||||
|
||||
@code
|
||||
function MODULE_content_multigroup_no_remove_widgets() {
|
||||
return array('WIDGET_NAME_1', 'WIDGET_NAME_2', ...);
|
||||
}
|
||||
@endcode
|
||||
|
||||
The Content Taxonomy module [1] is an example where it implements the previous
|
||||
hooks for a few widgets.
|
||||
|
||||
[1] http://drupal.org/project/content_taxonomy
|
||||
|
||||
If a simple array of widgets is not sufficient to test whether this action
|
||||
will work, modules can implement hook_content_multigroup_allowed_in()
|
||||
and hook_content_multigroup_allowed_out() to intervene. Both hooks should
|
||||
return an array as in the following example:
|
||||
|
||||
@code
|
||||
function MODULE_content_multigroup_allowed_in() {
|
||||
return array(
|
||||
'allowed' => FALSE,
|
||||
'message' => t('This change is not allowed. Reason here...'),
|
||||
);
|
||||
}
|
||||
@endcode
|
||||
|
||||
Custom code and modules that add fields to groups outside of the UI should
|
||||
use content_multigroup_allowed_in() and content_multigroup_allowed_out() to
|
||||
test whether fields are allowed in or out of a Multigroup. These functions
|
||||
can be located in content_multigroup.admin.inc.
|
||||
|
||||
|
||||
VIEWS INTEGRATION
|
||||
=================
|
||||
|
||||
For each multigroup, there is a new filter under "Content multigroup" category
|
||||
in Views that provides a method to synchronize fields by delta.
|
||||
|
||||
|
||||
TROUBLESHOOTING
|
||||
===============
|
||||
|
||||
The most likely cause of problems with field modules not working in multigroup
|
||||
is if they wipe out #element_validate with their own validation functions, or
|
||||
they hard-code assumptions into submit or validation processes that the form
|
||||
is structured in the usual field => delta => value order instead of allowing
|
||||
for the possibility of a different structure. See Nodereference for an example
|
||||
of a field that handles validation without making assumptions about the form
|
||||
structure.
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
About CKEditor for Drupal
|
||||
-------------------------
|
||||
This module allows Drupal to replace textarea fields with CKEditor.
|
||||
CKEditor is an online rich text editor that can be embedded inside web pages.
|
||||
It is a WYSIWYG (What You See Is What You Get) editor which means that the
|
||||
text edited in it looks as similar as possible to the results end users will
|
||||
see after the document gets published. It brings to the Web popular editing
|
||||
features found in desktop word processors such as Microsoft Word and
|
||||
OpenOffice.org Writer. CKEditor is truly lightweight and does not require any
|
||||
kind of installation on the client computer.
|
||||
|
||||
Help & Documentation
|
||||
--------------------
|
||||
If you are looking for more information, have any trouble with the configuration of the module
|
||||
or found an issue, please visit the official project page:
|
||||
http://drupal.org/project/ckeditor
|
||||
|
||||
Extensive CKEditor for Drupal documentation is available at:
|
||||
http://docs.cksource.com/CKEditor_for_Drupal/Open_Source/Drupal_6
|
||||
|
||||
Contribution
|
||||
------------
|
||||
If you would like to help in the development of the module, we encourage you to join our team.
|
||||
Any help will be greatly appreciated!
|
||||
|
||||
Module Information and License
|
||||
----------------------------
|
||||
CKEditor - The text editor for the Internet
|
||||
Copyright (c) 2003-2013, CKSource - Frederico Knabben. All rights reserved.
|
||||
http://cksource.com/
|
||||
|
||||
Licensed under the terms of the GNU Lesser General Public License:
|
||||
http://www.opensource.org/licenses/lgpl-license.php
|
||||
|
||||
For further information visit:
|
||||
http://ckeditor.com/
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
CKEDITOR LINK - A PLUGIN TO EASILY CREATE LINKS TO DRUPAL INTERNAL PATHS
|
||||
http://drupal.org/project/ckeditor_link
|
||||
|
||||
|
||||
|
||||
REQUIREMENTS
|
||||
The CKEditor module or the Wysiwyg module
|
||||
The CKEditor editor
|
||||
Clean URLs need to be enabled.
|
||||
|
||||
|
||||
|
||||
INSTALLATION
|
||||
Copy the ckeditor_link folder to your modules directory.
|
||||
Go to admin/build/modules and enable the module.
|
||||
|
||||
*Set permissions*
|
||||
Go to admin/user/permissions and grant the CKEditor Link related permissions to
|
||||
the desired roles.
|
||||
|
||||
*When using the CKEditor module*
|
||||
Go to admin/settings/ckeditor and edit the desired profile.
|
||||
Under "Editor appearance" > "Plugins", check the "CKEditor Link" box.
|
||||
Save changes.
|
||||
|
||||
*When using the Wysiwyg module*
|
||||
Go to admin/settings/wysiwyg and edit the CKEditor profile.
|
||||
Under "Buttons and plugins", check both "Link" and "CKEditor Link" boxes.
|
||||
Save changes.
|
||||
|
||||
*Set up CKEditor Link Filter*
|
||||
Go to admin/settings/filters and edit the desired input format.
|
||||
Check the "CKEditor Link Filter" box.
|
||||
Save changes.
|
||||
|
||||
If you use other path converting filters like Pathologic or Path Filter, make
|
||||
sure that CKEditor Link Filter comes before them:
|
||||
Edit the input format again.
|
||||
Click on the "Rearrange" tab.
|
||||
Drag and drop CKEditor Link Filter before these filters in the list.
|
||||
Save changes.
|
||||
|
||||
*Configure CKEditor Link*
|
||||
Go to admin/settings/ckeditor_link.
|
||||
Change settings as desired.
|
||||
Save changes.
|
||||
|
||||
|
||||
|
||||
EXTENDING CKEDITOR LINK
|
||||
Developers, see the ckeditor_link.api.php file.
|
||||
|
||||
|
||||
|
||||
CONTACT
|
||||
Henri MEDOT <henri.medot[AT]absyx[DOT]fr>
|
||||
http://www.absyx.fr
|
||||
|
|
@ -1,183 +0,0 @@
|
|||
------------------The Computed Field Drupal Module----------------------------
|
||||
|
||||
Computed Field is a cck module which lets you add a computed field to custom
|
||||
content types. You can choose whether to store your computed field in the
|
||||
database. You can also choose whether to display the field, and how to format
|
||||
it. The value of the field is set using php code, so it can draw on anything
|
||||
available to drupal, including other fields, the current user, database
|
||||
tables, etc. The drawback of this is of course that you need to know some php
|
||||
to use it.
|
||||
|
||||
Computed Field requires the content module (cck).
|
||||
|
||||
-------------------------Update-------------------------------
|
||||
|
||||
As of 2006-8-11 the 'display format' setting has changed. You'll need to
|
||||
update any existing computed fields: If your display format was 'This is the
|
||||
value: %value', then change it to '$display = "This is the value: " .
|
||||
$node_field_item['value'];'
|
||||
|
||||
|
||||
-------------------------Usage--------------------------------
|
||||
|
||||
----------Getting Started-----------------------------------
|
||||
|
||||
Before you can use Computed Field, you'll need to get CCK and enable (at the
|
||||
very least) the 'content' module. You will probably also want to enable the
|
||||
other cck modules, such as 'text', 'number', 'date', etc.
|
||||
|
||||
To add a computed field to a content type, go to administer > content >
|
||||
content types, select the content type you want to add to, and click on the
|
||||
'add field' tab. One of the field types available should be 'Computed', and it
|
||||
should have one bullet point under it, also labelled 'Computed'. If you select
|
||||
this, give your field a name, and submit the form, you will get to the
|
||||
configuration page for your new computed field.
|
||||
|
||||
|
||||
--------Configuration---------------------------------------
|
||||
|
||||
A Computed Field can be configured with the usual cck field options, as well
|
||||
as the following extra options:
|
||||
|
||||
Computed Code -- This is the code that will assign a value to your computed
|
||||
field. It should be valid php without the <?php ?> tags.
|
||||
|
||||
Display Format -- This is also php code which should assign a string to the
|
||||
$display variable. It has '$node_field_item['value']' available, which is the
|
||||
value of the computed field. It also has '$field' available, and you can call
|
||||
any drupal functions you want to display your field.
|
||||
|
||||
Store using the database settings below -- If this is checked then the field
|
||||
is computed on node save and stored. If it isn't stored then it will be
|
||||
recomputed every time you view a node containing this field.
|
||||
|
||||
Database Storage Settings
|
||||
Data Type -- This is the sql data type to use to store the field. Let us
|
||||
know if you need any other storage types, or if you would like an 'other'
|
||||
option :).
|
||||
|
||||
Data Length (varchar/text) -- The length of the field in the database. For
|
||||
storing usernames or other short text with a varchar field, 32 may be
|
||||
appropriate. Only valid for varchar or text fields.
|
||||
|
||||
Data Size (int/float) -- The size of the field stored in the database.
|
||||
Only valid for int or float fields.
|
||||
|
||||
Data Precision (decimal) -- The total number of digits to store in the
|
||||
database, including those to the right of the decimal. Only valid for
|
||||
decimal fields.
|
||||
|
||||
Data Scale (decimal) -- The number of digits to the right of the decimal.
|
||||
Only valid for decimal fields.
|
||||
|
||||
Default Value -- Leave this blank if you don't want the database to store
|
||||
a default value if your computed field's value isn't set.
|
||||
|
||||
Not NULL -- Leave unchecked if you want to allow NULL values in the
|
||||
database field.
|
||||
|
||||
Sortable -- Used in Views to allow sorting a column of this field.
|
||||
|
||||
|
||||
--------Examples------------------------------------------
|
||||
|
||||
Here are some usage examples to get you started with Computed
|
||||
Field.
|
||||
|
||||
-----Make a node link to itself-----------------
|
||||
|
||||
This example isn't very useful, but it demonstrates how to get
|
||||
hold of the nid.
|
||||
|
||||
In your computed field's configuration:
|
||||
|
||||
- Computed Code:
|
||||
// store the nid in our computed field
|
||||
$node_field[0]['value'] = $node->nid;
|
||||
|
||||
- Check 'Display this field'
|
||||
|
||||
- Display Format:
|
||||
$display = l('A link to this node', 'node/'.$node_field_item['value']);
|
||||
|
||||
- Uncheck 'Store using the database settings below'. You could store this if
|
||||
you wanted to, but it's not costly to compute this field and is already
|
||||
stored in the node table. One reason why you may want to store it is if you
|
||||
want the value available to Views.
|
||||
|
||||
When you display a node of the content type containing this field it should
|
||||
now have a link to itself.
|
||||
|
||||
-----Adding two other fields----------------------
|
||||
Imagine you have two existing number fields, called field_product_price and
|
||||
field_postage_price. You want to create a computed field field_total_cost
|
||||
which adds these two fields. Create a new computed field with the name 'Total
|
||||
Cost', and in your computed field's configuration set the following:
|
||||
|
||||
- Computed Code:
|
||||
$node_field[0]['value'] =
|
||||
$node->field_product_price[0]['value'] +
|
||||
$node->field_postage_price[0]['value'];
|
||||
|
||||
- Check 'Display this field'
|
||||
|
||||
- Display Format:
|
||||
$display = '$' . $node_field_item['value'];
|
||||
|
||||
- Check 'Store using the database settings below'
|
||||
|
||||
- Data Type: decimal
|
||||
|
||||
- Decimal Precision: 10
|
||||
|
||||
- Decimal Scale: 2
|
||||
|
||||
- Default Value: 0.00
|
||||
|
||||
- Check 'Not NULL'
|
||||
|
||||
- Check 'Sortable'
|
||||
|
||||
|
||||
-----Calculating a Duration given a start and end time-----
|
||||
|
||||
This example uses KarenS' date module (http://drupal.org/project/date) to
|
||||
create two date fields field_start_time and field_end_time which record hours
|
||||
and minutes. We then create a new computed field to work out the duration as a
|
||||
decimal number of hours (so 1.5 is 1hour, 30minutes).
|
||||
|
||||
Computed field settings:
|
||||
|
||||
- Computed Code:
|
||||
$start = $node->field_start_time[0]['value'];
|
||||
$end = $node->field_end_time[0]['value'];
|
||||
$start_decimal = $start['hours'] + ($start['minutes'] / 60);
|
||||
$end_decimal = $end['hours'] + ($end['minutes'] / 60);
|
||||
$node_field[0]['value'] = $end_decimal - $start_decimal;
|
||||
|
||||
- Check 'Display this field'</li>
|
||||
|
||||
- Display Format:</b><code>
|
||||
$display = $node_field_item['value'] . " hours";
|
||||
|
||||
- Check 'Store using the database settings below
|
||||
|
||||
- Data Type:</b> float
|
||||
|
||||
- Data Size:</b> normal
|
||||
|
||||
- Check 'Sortable'
|
||||
|
||||
Now if you set the start time field to 9am and the end time to 11:30am, your
|
||||
computed field will store the value '2.5' and display '2.5 hours'.
|
||||
|
||||
|
||||
-----Send more examples!---------------------------------
|
||||
|
||||
If you have another useful (or instructive) example send it to me
|
||||
(http://drupal.org/user/59132/contact) and I'll add it here for the benefit of
|
||||
humankind.
|
||||
|
||||
-----------------------About Computed Field-----------------------------------
|
||||
Computed Field was created by Agileware (http://www.agileware.net).
|
||||
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
Content Taxonomy:
|
||||
*****************
|
||||
|
||||
This module provides a field type for cck for referencing taxonomy terms.
|
||||
|
||||
The content_taxonomy.module implements all basic field functions.
|
||||
The other modules offer different widgets (selects,..)
|
||||
|
||||
Installation:
|
||||
-------------
|
||||
1. Install this files into the modules directory.
|
||||
2. Enable content_taxonomy.module in the admin/modules page
|
||||
3. Enable wanted widgets in admin/modules (e.g. content_taxonomy_select.module) Note: all require content_taxonomy.module!
|
||||
4. Optional enable content_taxonomy_views.module for improved taxonomy-views support
|
||||
|
||||
Settings:
|
||||
---------
|
||||
For every field you have to select the vocabulary and optional a parent term in the field settings.
|
||||
If a parent is selected, only children of this parent will be given to the form, else the whole vocabulary.
|
||||
Additional you can choose whether the term is saved as a real tag in the term_node table (standard)
|
||||
or the term is only saved in a cck-table (so not a real term - node connection)
|
||||
|
||||
|
||||
|
||||
content_taxonomy_options:
|
||||
-------------------------
|
||||
provides a options widget type
|
||||
this includes:
|
||||
- radios/checkboxes (depends on single/multiple)
|
||||
- multiple/single select field (opt-groups are possible)
|
||||
|
||||
content_taxonomy_autocomplete:
|
||||
------------------------------
|
||||
provides autocomplete. synonyms are considered by this autocomplete. Optional you can restrict the
|
||||
saving of new terms.
|
||||
|
||||
content_taxonomy_activeselect:
|
||||
------------------------------
|
||||
requires the activeselect.module
|
||||
offers dependent selects, at the moment 2-3 bars are possible
|
||||
|
||||
|
||||
|
||||
Author:
|
||||
-------
|
||||
Matthias Hutterer
|
||||
mh86@drupal.org
|
||||
m_hutterer@hotmail.com
|
||||
|
|
@ -1,407 +0,0 @@
|
|||
/* $Id $ */
|
||||
|
||||
Custom Breadcrumbs 6.x-1.x (See below for 6.x-2.x)
|
||||
--------------------------------------------------
|
||||
Summary
|
||||
-------
|
||||
* Enable the module
|
||||
* Assign 'administer custom breadcrumbs' permission to those roles that should
|
||||
be allowed to add/edit/delete custom breadcrumbs.
|
||||
* Assign 'use php in custom breadcrumbs' to roles that should be allowed to use
|
||||
php to determine breadcrumb visibility.
|
||||
* Go to Administer > Site building > Custom breadcrumbs to add new breadcrumbs
|
||||
* Click "Add a new custom breadcrumb"
|
||||
* Choose the node type to create a breadcrumb trail for
|
||||
* For the titles, put each "crumb" one line after another (There is no need to
|
||||
put in "home"):
|
||||
|
||||
Item 1
|
||||
SubItem A
|
||||
SuperSubItem X
|
||||
|
||||
* For the paths, put the path to each crumb starting after the domain name.
|
||||
Don't include a leading or trailing slash.
|
||||
|
||||
item1
|
||||
item-1/subitem-a
|
||||
item-1/subitem-a/supersubitem-x
|
||||
|
||||
* Click save to save the breadcrumb
|
||||
* Visit the page and your breadcrumb should appear!
|
||||
|
||||
Description
|
||||
-----------
|
||||
As the name suggests, Custom Breadcrumbs allows you to create and modify your
|
||||
own breadcrumbs based on node type. After enabling the module, click on
|
||||
Administer > Site building > Custom breadcrumbs. You'll be abel to add new
|
||||
breadcrumbs from this page.
|
||||
|
||||
Clicking on that link, you have the option to select the node type the
|
||||
breadcrumb will apply to. There are two text fields below-- "Titles" and
|
||||
"Paths." When creating a breadcrumb, you're simply creating a link. In the
|
||||
custom breadcrumbs interface "Titles" describes the text of the breadcrumb
|
||||
while "Paths" describes the Drupal path the breadcrumb links to. Each Title
|
||||
must have a corresponding Path.
|
||||
|
||||
To give a very simple example of how to use this module, let's say I have a
|
||||
blog on my web site called "Deep Thoughts." To create this, I use the Views
|
||||
module to create a page at /blog that displays all the node types "blog post."
|
||||
Whenever a user views a blog post I want the breadcrumb to show
|
||||
Home > Deep Thoughts instead of simply Home. To do this I would simply type
|
||||
"Deep Thoughts" in the "Titles" field and and "blog" in the "Paths" field and
|
||||
save my breadcrumb.
|
||||
|
||||
Using the Tokens module, the Custom breadcrumbs module becomes much more
|
||||
flexible because breadcrumbs can become dynamic. You can create a breadcrumb
|
||||
like Home > Deep Thoughts > [Month of Blog Post] [Year of Blog Post], where
|
||||
"Deep Thoughts" links to my main blog page and "[Month of Blog Post]
|
||||
[Year of Blog Post]" links to a view that shows only blog posts from the month
|
||||
and year the blog post was created (e.g. June 2007). For this, you would do
|
||||
the following:
|
||||
|
||||
Node Type:
|
||||
Blog Post
|
||||
|
||||
Titles:
|
||||
Deep Thoughts
|
||||
[month] [yyyy]
|
||||
|
||||
Paths:
|
||||
blog
|
||||
blog/[mm]_[yyyy]
|
||||
|
||||
(where of course, blog/[mm]_[yyyy] is the path to the view of blog posts from
|
||||
that month and year). So if you created a blog pos on June 13, 2007 your
|
||||
breadcrumb would show Home > Deep Thoughts > June 2007 and "June 2007" links
|
||||
to "blog/06_2007" which is a view of all blog posts from June 2007.
|
||||
|
||||
Also, note that Custom Breadcrumbs doesn't actually check to be sure that a
|
||||
particular path exists, so you'll have to check yourself to avoid 404 errors.
|
||||
|
||||
Only users with 'administer custom breadcrumbs' permission will be allowed to
|
||||
create or modify custom breadcrumbs.
|
||||
|
||||
Breadcrumb Visibility
|
||||
---------------------
|
||||
Users given 'use php in custom breadcrumbs' permission can include a php code
|
||||
snippet that returns TRUE or FALSE to control whether or not the breadcrumb is
|
||||
displayed. Note that this code has access to the $node variable, and can check
|
||||
its type or any other property. Tokens should not be used in the visibility
|
||||
code snippet, since they will not be replaced.
|
||||
|
||||
Special Identifiers
|
||||
-------------------
|
||||
The following identifiers can be used to achieve a special behavior:
|
||||
<pathauto> - will clean any path using the current pathauto module settings,
|
||||
if that module is installed.
|
||||
<none> - can be used as a path to have a breadcrumb element that is not
|
||||
hyperlinked.
|
||||
|
||||
Identifiers should be added to the paths area in the following format:
|
||||
identifier|path. To be recognized, the identifier must be enclosed in angular
|
||||
brackets, and proceed any part of the path:
|
||||
|
||||
For example: <pathauto>|[ogname-raw]
|
||||
|
||||
|
||||
Custom Breadcrumbs 2.0
|
||||
----------------------
|
||||
|
||||
Summary
|
||||
-------
|
||||
* Enable the module and any option submodules (see below for details)
|
||||
* Assign 'administer custom breadcrumbs' permission to those roles that should
|
||||
be allowed to add/edit/delete custom breadcrumbs.
|
||||
* Assign 'use php in custom breadcrumbs' to roles that should be allowed to use
|
||||
php to determine breadcrumb visibility.
|
||||
* Go to Administer > Site Configuration > Custom breadcrumbs Settings to select
|
||||
the 'Home' breacrumb text and possibly other global settings.
|
||||
* Go to Administer > Site building > Custom breadcrumbs to add new breadcrumbs
|
||||
* To add a breadcrumb, click on one of the tabs at the top of the page. For
|
||||
example, click 'Node' to create a custom breadcrumb based on node type.
|
||||
* Fill in the required information for the breadcrumb (varies depending on
|
||||
breadcrumb type, see below).
|
||||
* For the titles, put each "crumb" one line after another (There is no need to
|
||||
put in "home")
|
||||
* (optional) For each crumb title you can specify a title attribute ("tooltip")
|
||||
to add to the link. Separate the crumb title and the title attribute with a
|
||||
pipe (|) symbol:
|
||||
|
||||
Item 1
|
||||
SubItem A|Title attribute for SubItemA (optional)
|
||||
SuperSubItem X
|
||||
|
||||
* For the paths, put the path to each crumb starting after the domain name.
|
||||
Don't include a leading or trailing slash.
|
||||
|
||||
item1
|
||||
item-1/subitem-a
|
||||
item-1/subitem-a/supersubitem-x
|
||||
|
||||
* Click save to save the breadcrumb
|
||||
* Visit the page and your breadcrumb should appear!
|
||||
|
||||
New Features
|
||||
------------
|
||||
In the 6.x-2.x release, custom breadcrumbs has many new features which are
|
||||
available through optional modules in the custom breadcrumbs package. The base
|
||||
module, required by all the others, is still custom_breadcrumbs. This module
|
||||
handles custom breadcrumbs based on node type as described above. The following
|
||||
optional modules can also be installed to provide custom breadcrumbs in a
|
||||
variety of situations:
|
||||
|
||||
+ custom_breadcrumbs_views provides custom breadcrumbs on views pages.
|
||||
Once this module is enabled, a new "Views" tab will appear at
|
||||
admin/build/custom_breadcrumbs. To add a views page breadcrumb, click on the
|
||||
tab and then select the view from list of available views. Fill in the
|
||||
visibility, title and paths sections as described above, and your breadcrumb
|
||||
should appear on your views page. Note that token substitution is possible
|
||||
with global and user tokens only. The $view object is available for use in
|
||||
the php_visibility section.
|
||||
|
||||
+ custom_breadcrumbs_paths provides custom breadcrumbs on nodes and views at
|
||||
a specified path (url). Once this module is enabled, a new "Path" tab will
|
||||
appear at admin/build/custom_breadcrumbs. To add a breadcrumb for a node
|
||||
or a view at a specific path, just enter the Drupal path in the Specific
|
||||
Path section. Fill in the visibility, title and paths sections as
|
||||
described above, and save the breadcrumb. Now your breadcrumb should appear
|
||||
on the node or view at the specific path that you selected. Note that custom
|
||||
breadcrumbs does not check the validity of the entered path. When entering a
|
||||
path for a particular language (see below), do not specify the two-letter
|
||||
language prefix. Custom breadcrumbs will assume the correct prefix according
|
||||
to the selected language. To use '*' as a wildcard, go to custom breadcrumbs
|
||||
configuration page at /admin/settings/custom-breadcrumbs and select the
|
||||
'Use wildcard pattern matching in paths' option in the advanced settings
|
||||
section. When this option is enabled, the breadcrumb that best matches the
|
||||
path will be selected. The best match is determined by the depth at which
|
||||
the first wildcard appears. For example, if the path is path/to/some/content
|
||||
and breadcrumbs have been defined for path/to/* and path/to/some/*, the
|
||||
latter will be chosen as the best match.
|
||||
|
||||
+ custom_breadcrumbs_taxonomy provides custom breadcrumbs on taxonomy term
|
||||
pages, views, and for nodes that are assigned a taxonomy vocabulary or term.
|
||||
Once this module is enabled, two new tabs will appear appear at
|
||||
admin/build/custom_breadcrumbs: Term and Vocabulary. Breadcrumb generation
|
||||
can be handled in two different ways. If 'use the taxonomy term hierarchy'
|
||||
is checked at custom breadcrumbs configuration page, then breadcrumbs will
|
||||
be generated similarly to the taxonomy_breadcrumb module. Otherwise,
|
||||
breadcrumb generation will be according to the standard custom breadcrumbs
|
||||
approach.
|
||||
|
||||
In taxonomy breadcrumb mode, the breadcrumb trail is automatically
|
||||
constructed based on the taxonomy term hierarchy:
|
||||
[HOME] >> [VOCABULARY] >> TERM >> [TERM] >> [TITLE]. In this mode the
|
||||
breadcrumb titles are the term and vocabulary names. The paths these titles
|
||||
are linked to can be assigned via the Term and Vocabulary tabs at
|
||||
admin/build/custom_breadcrumbs. Providing a path for a vocabulary will enable
|
||||
the [VOCABULARY] portion of the breadcrumb. The path for a term can
|
||||
similarly be set, but if one is not provided the default taxonomy/term/tid
|
||||
(where tid is a number, the taxonomy term id) will be used. Select the types
|
||||
of nodes to include or exclude at the custom breadcrumbs configuration
|
||||
settings page. The option to add the node title at the end of the breadcrumb
|
||||
trail can also be enabled on that page. There is also an option to append
|
||||
the current taxonomy term to the breadcrumb on taxonomy term pages
|
||||
(defined to be any page with drupal path */taxonomy/term/*).
|
||||
|
||||
In the standard custom breadcrumbs mode, you can provide the titles and paths
|
||||
for constructing the breadcrumb trail on nodes that have defined taxonomy
|
||||
terms. Note that if a node has more than one term, the lightest term in the
|
||||
lightest vocabulary with a defined custom breadcrumb will be used.
|
||||
|
||||
Note: do not use this module and the taxonomy_breadcrumb module at the same
|
||||
time. Custom_breadcrumbs_taxonomy has extended the functionality of
|
||||
taxonomy_breadcrumb, so that module is not needed if you are using
|
||||
custom_breadcrumbs.
|
||||
|
||||
While at admin/settings/custom-breadcrumbs, go ahead and enable any
|
||||
additional taxonomy breadcrumb options that suits your needs. If you are
|
||||
using views to override taxonomy term pages, then be sure to enable the
|
||||
"Use taxonomy breadcrumbs for views" option.
|
||||
|
||||
+ custom_breadcrumbsapi provides a simple api that allows custom breadcrumbs to
|
||||
be defined for module pages implementing the api. Module developers need to
|
||||
provide a modulename_custom_breadcrumbsapi() function that returns an array
|
||||
containing the names of the module pages for which custom breadcrumbs may be
|
||||
defined.
|
||||
|
||||
The following is an example that could be used with the forum module.
|
||||
|
||||
/**
|
||||
* Implementation of hook_custom_breadcrumbsapi().
|
||||
* Allow custom breadcrumbs for the following module pages.
|
||||
*/
|
||||
function forum_custom_breadcrumbsapi() {
|
||||
return array('forum listing');
|
||||
}
|
||||
|
||||
Then, in the callback functions for each of those pages, the following line
|
||||
must be inserted within the function (preferably after defining $breadcrumb
|
||||
but before setting the breadcrumb):
|
||||
|
||||
drupal_alter('breadcrumb', $breadcrumb, 'module_page_name');
|
||||
|
||||
Continuing with the forum module example, 'module_page_name' would be
|
||||
replaced with 'forum listing'.
|
||||
|
||||
custom_breadcrumbsapi can also provide custom breadcrumbs for modules
|
||||
implementing theme templates (e.g. files ending in .tpl.php). To add a
|
||||
custom breadcrumb when a specific theme template file is called, click
|
||||
on the module page tab at admin/build/custom_breadcrumbs. Select the
|
||||
template file from the list of theme templates (determined from the
|
||||
theme registry). Then fill in the usual custom breadcrumbs information
|
||||
such as titles as paths. If using a php snippet for breadcrumb visibility
|
||||
or to specify titles and paths (see below), you have access to the template
|
||||
variables through $variables, an associative array defined by the module
|
||||
providing the template. See the documentation in the template file for
|
||||
details. For example, if a template file uses the variable $foo, then
|
||||
access to that variable would be through $variables['foo'].
|
||||
|
||||
User Interface
|
||||
--------------
|
||||
The user interface has been modified for Custom Breadcrumbs 2.0. Breadcrumbs
|
||||
from all custom breadcrumbs modules are tabulated at
|
||||
admin/build/custom_breadcrumbs. The table can be sorted according to
|
||||
breadcrumb name, type, language (if locale is enabled) by clicking on the
|
||||
column headers. The table can also be filtered to display breadcrumbs of a
|
||||
specific type, language, or combination of the two.
|
||||
|
||||
A new custom breadcrumbs fieldset has been added to node edit pages. All
|
||||
defined breadcrumbs for a particular node are displayed here, with an option to
|
||||
edit each. If no breadcrumbs have been defined for a particular node, then a
|
||||
link can be followed back to admin/build/custom_breacrumbs to add a custom
|
||||
breadcrumb.
|
||||
|
||||
Languages
|
||||
---------
|
||||
If the core Locale module is enabled, then an additional option to specify the
|
||||
language for the breadcrumb is available when constructing the breadcrumb trail
|
||||
(with any of the custom breadcrumb modules).
|
||||
|
||||
HOME breadcrumb
|
||||
---------------
|
||||
The text to display at beginning of the breadcrumb trail can be assigned from
|
||||
the custom breadcrumb configuration settings page. Typically this is Home or
|
||||
your site name. You can leave it blank to have no home breadcrumb. As with
|
||||
normal crumb titles, you can optionally specify a title attribute ("tooltip")
|
||||
for the crumb. Just separate the crumb text and the title attribute text with a
|
||||
pipe (|) symbol (i.e. Home crumb text|attribute title text). There is
|
||||
also an advanced setting to set the Home breadcrumb text on ALL pages, not
|
||||
just those with defined custom breadcrumbs. You can also use this feature to
|
||||
remove the home breadcrumb on all pages on the site - just enable the advanced
|
||||
setting and then leave the home breadcrumb text blank.
|
||||
|
||||
It is possible to translate the home reference title from custom breadcrumbs
|
||||
using the i18n module. Just put this in your settings.php:
|
||||
|
||||
$conf['i18n_variables'] = array(
|
||||
//custom breadcrumbs
|
||||
'custom_breadcrumb_home',
|
||||
);
|
||||
|
||||
Then you can change it for each language at
|
||||
http://example.com/#lang-prefix#/admin/settings/custom-breadcrumbs.
|
||||
|
||||
See http://drupal.org/node/313272 for additional information.
|
||||
|
||||
Use PHP in breadcrumb titles and paths
|
||||
--------------------------------------
|
||||
If this advanced option is enabled at admin/settings/custom-breadcrumbs, then
|
||||
users given 'use php in custom breadcrumbs' permission can include small php
|
||||
code snippets (less than 250 characters)in the titles and/or paths fields of
|
||||
the add breadcrumb form. Be careful when enabling this option, as the incorrect
|
||||
use of php can break your site.
|
||||
|
||||
There are a couple of ways to use php in breadcrumbs and titles. One way is to
|
||||
return an array of breadcrumb titles in the titles text field and a
|
||||
corresponding array of breadcrumb paths in the paths text field such as
|
||||
|
||||
Titles:
|
||||
<?php return array('title-1','title-2','title-3');?>
|
||||
|
||||
Paths:
|
||||
<?php return array('path/to/title-1','path/to/title-2','path/to/title-3');?>
|
||||
|
||||
Sometimes, it may be more convient to assign the titles and paths in the same
|
||||
code snippet, so you can also return an associate array with elements 'titles'
|
||||
and 'paths' that contain the titles and paths arrays, respectively.
|
||||
For example,
|
||||
|
||||
Titles:
|
||||
<?php $titles = array('title-1','title-2','title-3');
|
||||
$paths = array('path/to/title-1','path/to/title-2','path/to/title-3');
|
||||
return array('titles' => $titles, 'paths' => $paths); ?>
|
||||
|
||||
(In this case, the paths text field will be ignored, so you can leave it
|
||||
empty).
|
||||
|
||||
When defined, appropriate objects such as $node, $term, or $view, will be
|
||||
available for these code snippets. Note that if this option is enabled and an
|
||||
array is not returned, then the module defaults to the standard operation of
|
||||
using each line of the titles and paths text fields to define a part of the
|
||||
breadcrumb.
|
||||
|
||||
For longer code snippets (greater than 250 characters), you can save your code
|
||||
snippet in an include file and use a php require_once statement in the titles
|
||||
and/or paths section of your custom breadcrumb to include and evaluate your
|
||||
code. See http://drupal.org/node/654766 for an example of this.
|
||||
|
||||
Add CSS classes to custom breadcrumb elements
|
||||
---------------------------------------------
|
||||
|
||||
You can enable this feature on the custom breadcrumbs configuration screen
|
||||
under the HTML element identifiers section. There are several options that
|
||||
provide html class identifiers for theming custom breadcrumb links, including
|
||||
add a 'custom-breadcrumbs-home' ID attribute to the home breadcrumb item,
|
||||
adding numbered class attributes 'custom-breadcrumbs-item-N' for each
|
||||
breadcrumb item, adding even and odd classes to breadcrumb items and storing an
|
||||
identifier that is unique for each defined custom breadcrumbs. Using this
|
||||
last option requires modifying your sites phptemplate_breadcrumb (or theme
|
||||
override) function to actually add the class name to the breadcrumb container.
|
||||
The class name is returned as a string by the function
|
||||
custom_breadcrumbs_unique_breadcrumb_id(). The identifier will be of the form
|
||||
'custom-breadcrumbs-type-id'where type is the breadcrumb type (node, panels,
|
||||
path, views or taxonomy) and id is the breadcrumb id number.
|
||||
See http://drupal.org/node/643796#comment-2532998 for more information on this
|
||||
feature.
|
||||
|
||||
Special Identifiers
|
||||
-------------------
|
||||
In Custom Breadcrumbs 2.0, Special identifiers are now provided as a separate,
|
||||
optional module - custom_breadcrumbs_identifiers. At present, this module
|
||||
provides the following identifiers:
|
||||
|
||||
<none> - Produces a plain text crumb. This identifier should not
|
||||
be used with the pipe (|) symbol.
|
||||
<pathauto> - Cleans the given path using your pathauto replacement
|
||||
rules.
|
||||
<book-hierarchy> - Provides crumbs for each parent node of a book page.
|
||||
Whatever is placed in the corresponding position of the
|
||||
title area will be ignored. It should not be used with
|
||||
the pipe (|) symbol.
|
||||
<page-title> - Provides a plain text crumb using the page title. Whatever
|
||||
is placed in the corresponding position of the title area
|
||||
will be ignored. It should not be used with the pipe (|)
|
||||
symbol.
|
||||
<menu-parent-trail> - Produces crumbs for each parent item for the given path.
|
||||
The title information for this line will be ignored
|
||||
because the menu link titles are used. If a path is not
|
||||
provided following the pipe (|) symbol, the current path
|
||||
with be used.
|
||||
|
||||
Additional special identifiers can be developed and added by contributed
|
||||
modules that implement hook_cb_identifier_list(), to provide a description of
|
||||
the identifer, and hook_cb_identifier_values(), to prepare the appropriate
|
||||
crumb items. See the custom_breadcrumbs_identifiers.module for examples of
|
||||
how to do this.
|
||||
|
||||
Identifiers should be added to the paths area in the following format:
|
||||
identifier|path. To be recognized, the identifier must be enclosed in angular
|
||||
brackets, and proceed any part of the path:
|
||||
|
||||
For example: <pathauto>|[ogname-raw]
|
||||
|
||||
Note that not all identifiers require the use of |path.
|
||||
|
||||
Authors
|
||||
-------
|
||||
bennybobw, dbabbage, Michelle, MGN
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
|
||||
Custom search 6.x-1.x
|
||||
--------------------------
|
||||
|
||||
Install
|
||||
-------
|
||||
* Enable the module
|
||||
* Go to Administer > Settings > Custom search to change settings
|
||||
* Don't forget to set permissions, otherwise nobody will see the changes
|
||||
|
||||
Description
|
||||
-----------
|
||||
This module alters the default search box in many ways. If you need to have options available like in advanced search, but directly in the search box, this module is for you.
|
||||
|
||||
The module adds options to select:
|
||||
|
||||
- which content type(s) to search,
|
||||
- which specific module search to use (node, help, user or any module that implements search),
|
||||
- which taxonomy term to search in the results (by vocabulary).
|
||||
- For all these choices, there are options to switch between a select box, checkboxes or radio buttons, and also customize the selector label and the default - Any - text.
|
||||
|
||||
There are also options to:
|
||||
|
||||
- change the default search box label,
|
||||
- adds a default text in the search box,
|
||||
- change the default submit button text,
|
||||
- use an image instead of the submit button,
|
||||
- via a "tabledrag", the ordering of all the added options can be changed.
|
||||
|
||||
Finally, there's some javascript to:
|
||||
|
||||
- check if the search box is not empty on submit,
|
||||
- clear the default text on focus, and put it back on blur (if search box is empty),
|
||||
- handle checkboxes (deselect some checkbox if -Any-, or a special module search, is checked),
|
||||
- reselect options in the advanced search options (in results page).
|
||||
|
||||
|
||||
The module integrates well with Internationalization (i18nstrings).
|
||||
|
||||
This module is inspired by some modules that implements some of these options (search_config, search_type, custom_seach_box).
|
||||
|
||||
Author
|
||||
------
|
||||
jdanthinne
|
||||
|
|
@ -1,208 +0,0 @@
|
|||
CUSTOM ERROR README.txt
|
||||
=======================
|
||||
|
||||
This module allows the site admin to create custom error pages for
|
||||
HTTP status codes 403 (access denied) and 404 (not found), without the
|
||||
need to create nodes for each of them.
|
||||
|
||||
Main features:
|
||||
|
||||
* Configurable page title and descriptions.
|
||||
* There are no author and date/time headers as with normal nodes.
|
||||
* Any HTML formatted text can be be put in the page body.
|
||||
* The error pages are themeable.
|
||||
* Users who are not logged in and try to access an area that requires
|
||||
login will be redirected to the page they were trying to access after
|
||||
they login.
|
||||
* Allows custom redirects for 404s.
|
||||
|
||||
Since the error pages are not real nodes, they do not have a specific
|
||||
content type, and will not show up in node listings.
|
||||
|
||||
At present, the module can be set up to handle 403 and 404
|
||||
errors. Drupal only allows those two errors to be assigned custom
|
||||
pages. However, the design of the module is flexible and can
|
||||
accommodate future error codes easily.
|
||||
|
||||
|
||||
Installation:
|
||||
-------------
|
||||
|
||||
1. Install the customerror module directory in your modules directory.
|
||||
|
||||
2. Go to the Modules page
|
||||
- Enable the customerror module.
|
||||
- If you want to messages to contain PHP, enable the core
|
||||
PHP filter module.
|
||||
Click on Save configuration.
|
||||
|
||||
3. Configure Error reporting
|
||||
- Go to Administer -> Site configuration -> Error reporting
|
||||
- For 403 (access denied), enter the value:
|
||||
customerror/403
|
||||
- For 404 (not found), enter the value:
|
||||
customerror/404
|
||||
Click on Save configuration.
|
||||
|
||||
4. Configure the module:
|
||||
- Go to Administer -> Site configuration -> Custom error
|
||||
- Enter any title and description you want for the 404 (not found)
|
||||
and 403 (access denied) pages.
|
||||
- You can use any HTML tags to format the text.
|
||||
Click on Save configuration.
|
||||
|
||||
5. Test your error pages.
|
||||
- Copy your present admin page url.
|
||||
- Try to go to a non-existent Drupal page on your site.
|
||||
You should see your custom error page for 404 (not found) page.
|
||||
|
||||
- Log out from your site.
|
||||
- Paste the admin page url and try to go there.
|
||||
You should see your custom error page for 403 (access denied) page.
|
||||
|
||||
|
||||
Redirecting upon login
|
||||
----------------------
|
||||
|
||||
Here is an example of how to add custom PHP to a 403 to give the user
|
||||
the option to login:
|
||||
|
||||
<?php
|
||||
global $user;
|
||||
if ($user->uid == 0) {
|
||||
$output = '<p>';
|
||||
$output .= t('If your user account has access to this page, please !message.',
|
||||
array(
|
||||
'!message' => l(t('log in'), 'user'),
|
||||
)
|
||||
);
|
||||
$output .= '</p>';
|
||||
print $output;
|
||||
}
|
||||
?>
|
||||
|
||||
Note that customerror keeps track of what page the user is trying to
|
||||
access, so after logging in, the user will be redirected to that page.
|
||||
|
||||
|
||||
Theme to be used on the error page
|
||||
----------------------------------
|
||||
|
||||
If you've set an administration theme, the default is to use this on
|
||||
all pages where the path is "admin", including 403 and 404 error
|
||||
pages. You can overide this by specifying a theme for custom error
|
||||
different from "System default".
|
||||
|
||||
This setting has no effect if the administration theme is set to
|
||||
"<System default>".
|
||||
|
||||
|
||||
Custom redirects for 404 errors
|
||||
-------------------------------
|
||||
|
||||
It is possible to set up custom redirects for status code 404 (not
|
||||
found).
|
||||
|
||||
For example if you had a page called foo and a page called xyz, then
|
||||
you moved them to a page called bar, and abc respectively, you can
|
||||
setup a redirect pair of:
|
||||
|
||||
^foo$ bar
|
||||
^xyz$ abc
|
||||
|
||||
The first pair will transparently redirect users trying to access
|
||||
example.com/foo to example.com/bar. The second pair will
|
||||
transparently redirect users trying to access example.com/xyz to
|
||||
example.com/abc.
|
||||
|
||||
You can have multiple pairs of redirects. Each must be on a line by
|
||||
itself.
|
||||
|
||||
Note that the first argument is a regexp, and the second argument is a
|
||||
path. You have to use one space between them, and enter each pattern
|
||||
on a line by itself. You cannot use variables.
|
||||
|
||||
For more flexible URL rewriting, including variables, you may consider
|
||||
using an external URL rewrite engine, such as Apache mod_rewrite.
|
||||
|
||||
|
||||
FAQ
|
||||
---
|
||||
|
||||
* I want to prevent robots from indexing my custom error pages by
|
||||
setting the robots meta tag in the HTML head to NOINDEX.
|
||||
|
||||
- There is no need to. CustomError returns the correct HTTP status
|
||||
codes (403 and 404). This will prevent robots from indexing the
|
||||
error pages.
|
||||
|
||||
* I want to customize the custom error template output.
|
||||
|
||||
- In your site's theme, duplicate your page.tpl.php to be
|
||||
page-customerror.tpl.php and then make your modifications there.
|
||||
|
||||
* I want to have a different template for my 404 and 403 pages.
|
||||
|
||||
- Duplicate your page.tpl.php page to be page-customerror-404.tpl.php
|
||||
and page-customerror-403.tpl.php. You do not need a
|
||||
page-customerror.tpl.php for this to work.
|
||||
|
||||
* Some 403 errors (e.g. "http://example.org/includes") are served by
|
||||
the Apache web server and not by CustomError. Isn't that a bug?
|
||||
|
||||
- No. CustomError is only designed to provide a custom error page
|
||||
when the page is processed by Drupal. The .htaccess file that
|
||||
comes with Drupal will catch some attempts to access forbidden
|
||||
directories before Drupal even see the requests. These access
|
||||
attempts will get the default Apache 403 error document, unless
|
||||
you use the Apache ErrorDocument directive to override this, e.g:
|
||||
ErrorDocument 403 /error/403.html
|
||||
For more information about this, see:
|
||||
http://httpd.apache.org/docs/current/custom-error.html
|
||||
|
||||
* How can I get blocks to appear on the custom 403 and 404 pages?
|
||||
|
||||
- Blocks will not appear on the custom 403 and 404 pages produced by
|
||||
this module. If you want the blocks shown, either upgrade to the
|
||||
Drupal 7 version, or use the "404 Blocks" module as a workaround.
|
||||
|
||||
URLs:
|
||||
https://drupal.org/node/709298
|
||||
https://drupal.org/project/blocks404
|
||||
|
||||
|
||||
Database
|
||||
--------
|
||||
|
||||
This module does not require any new database tables to be installed.
|
||||
|
||||
|
||||
Bugs/Features/Patches
|
||||
---------------------
|
||||
|
||||
If you want to report a bug, request a feature, or submit a patch,
|
||||
please do so in the issue queue at the project page on the Drupal web
|
||||
site:
|
||||
|
||||
http://drupal.org/project/customerror
|
||||
|
||||
|
||||
Online documentation
|
||||
--------------------
|
||||
|
||||
For more documentation, please see:
|
||||
|
||||
https://drupal.org/node/2064843
|
||||
|
||||
Author
|
||||
------
|
||||
|
||||
Principal author is Khalid Baheyeldin
|
||||
(http://baheyeldin.com/khalid and http://2bits.com).
|
||||
|
||||
Auxiliary maintainer is Gisle Hannemyr
|
||||
(https://drupal.org/user/409554).
|
||||
|
||||
The authors can be contacted for paid customizations of this module
|
||||
as well as Drupal consulting, installation, development, and
|
||||
customizations.
|
||||
|
|
@ -1,307 +0,0 @@
|
|||
INFORMATION FOR DEVELOPERS
|
||||
|
||||
Once the Date API is installed, all functions in the API are available to be used
|
||||
anywhere by any module. If the Date Timezone module is installed, the system site
|
||||
timezone selector and the user timezone selectors are overwritten to allow the
|
||||
selection of timezone names instead of offsets. Proper timezone conversion
|
||||
requires knowledge of those timezone names, something that is not currently
|
||||
available in Drupal core, and the change in selectors makes it possible to track it.
|
||||
|
||||
In most cases, you should enable the Date Timezone module any time you use the
|
||||
Date API to be able to set the site and user timezone names. It is not enabled by
|
||||
default in case another module is setting timezone names in the database.
|
||||
|
||||
The API uses the PHP 5.2 date functions to create and manipulate dates, and
|
||||
contains an option module that will emulate those functions in earlier versions
|
||||
of PHP.
|
||||
|
||||
If you are using PHP 4 or PHP 5.0 or 5.1, native date handling won't work right.
|
||||
Install the Date_PHP4 module to enable wrapper functions so this code will work
|
||||
in old PHP versions.
|
||||
|
||||
Example, the following will create a date for the local value in one
|
||||
timezone, adjust it to a different timezone, then return the offset in seconds
|
||||
in the new timezone for the input date; The offset will be adjusted for both
|
||||
the timezone difference and daylight savings time, if necessary:
|
||||
|
||||
$date = date_create('2007-03-11 02:00:00', timezone_open('America/Chicago'));
|
||||
$chicago_time = date_format($date, 'Y-m-d H:i');
|
||||
|
||||
print 'At '. $chicago_time .' in Chicago, the timezone offset in seconds
|
||||
was '. date_offset_get($date);
|
||||
|
||||
date_timezone_set($date, timezone_open('Europe/Berlin');
|
||||
$berlin_time = date_format($date, 'Y-m-d H:i');
|
||||
|
||||
print 'It was '. $berlin_time .' in Berlin when it
|
||||
was '. $chicago_time .' in Chicago.';
|
||||
print 'At that time in Berlin, the timezone offset in seconds was
|
||||
'. date_offset_get($date);
|
||||
|
||||
A helper function is available, date_make_date($string, $timezone, $type),
|
||||
where $string is a unixtimestamp, an ISO date, or a string like YYYY-MM-DD HH:MM:SS,
|
||||
$timezone is the name of the timezone this date is in, and $type is the type
|
||||
of date it is (DATE_UNIX, DATE_ISO, or DATE_DATETIME). It create and return
|
||||
a date object set to the right date and timezone.
|
||||
|
||||
Simpletest tests for these functions are included in the package.
|
||||
|
||||
Available functions include the following (more documentation is provided in
|
||||
the files):
|
||||
|
||||
============================================================================
|
||||
Date PHP4 Module
|
||||
============================================================================
|
||||
PHP 4 substitutions for the PHP 5 date functions are supplied. Use the PHP 5
|
||||
functions in your code as they would normally be used and the PHP 4
|
||||
alternatives will be automatically be substituted in when needed.
|
||||
|
||||
You cannot do everything with these functions that can be done in PHP 5, but
|
||||
you can create dates, find timezone offsets, and format the results.
|
||||
Timezone handling uses native PHP 5 functions when available and degrades
|
||||
automatically for PHP 4 to use substitutions like those
|
||||
provided in previous versions of the Date and Event modules.
|
||||
|
||||
Read the doxygen documentation in this module for more information
|
||||
about using the functions in ways that will work in PHP 4.
|
||||
|
||||
Simpletest tests for the PHP 4 equivalent functions are included in the package.
|
||||
|
||||
The following functions are emulated in PHP4:
|
||||
date_create()
|
||||
date_date_set()
|
||||
date_format()
|
||||
date_offset_get()
|
||||
date_timezone_set()
|
||||
timezone_abbreviations_list()
|
||||
timezone_identifiers_list()
|
||||
timezone_offset_get()
|
||||
timezone_open()
|
||||
|
||||
============================================================================
|
||||
Preconfigured arrays
|
||||
============================================================================
|
||||
Both translated and untranslated values are available. The date_week_days_ordered()
|
||||
function will shift an array of week day names so it starts with the site's
|
||||
first day of the week, otherwise the weekday names start with Sunday as the first
|
||||
value, the expected order for many php and sql functions.
|
||||
|
||||
date_month_names();
|
||||
date_month_names_abbr();
|
||||
date_month_names_untranslated();
|
||||
date_week_days();
|
||||
date_week_days_abbr();
|
||||
date_week_days_untranslated();
|
||||
date_week_days_ordered();
|
||||
date_years();
|
||||
date_hours();
|
||||
date_minutes();
|
||||
date_seconds();
|
||||
date_timezone_names();
|
||||
date_ampm();
|
||||
|
||||
============================================================================
|
||||
Miscellaneous date manipulation functions
|
||||
============================================================================
|
||||
Pre-defined constants and functions that will handle pre-1970 and post-2038
|
||||
dates in both PHP 4 and PHP 5, in any OS. Dates can be converted from one
|
||||
type to another and date parts can be extracted from any date type.
|
||||
|
||||
DATE_DATETIME
|
||||
DATE_ISO
|
||||
DATE_UNIX
|
||||
DATE_ARRAY
|
||||
DATE_OBJECT
|
||||
DATE_ICAL
|
||||
|
||||
date_convert()
|
||||
date_is_valid();
|
||||
date_part_is_valid();
|
||||
date_part_extract();
|
||||
|
||||
============================================================================
|
||||
Date calculation and navigation
|
||||
============================================================================
|
||||
date_difference() will find the time difference between any two days, measured
|
||||
in seconds, minutes, hours, days, months, weeks, or years.
|
||||
|
||||
date_days_in_month();
|
||||
date_days_in_year();
|
||||
date_weeks_in_year();
|
||||
date_last_day_of_month();
|
||||
date_day_of_week();
|
||||
date_day_of_week_name();
|
||||
date_difference();
|
||||
|
||||
============================================================================
|
||||
Date regex and format helpers
|
||||
============================================================================
|
||||
Pre-defined constants, an array of date format strings and their
|
||||
equivalent regex strings.
|
||||
|
||||
DATE_REGEX_LOOSE is a very loose regex that will pull date parts out
|
||||
of an ISO date with or without separators, using either 'T' or a space
|
||||
to separate date and time, and with or without time.
|
||||
|
||||
date_format_date() is similar to format_date(), except it takes a
|
||||
date object instead of a timestamp as the first parameter.
|
||||
|
||||
DATE_FORMAT_ISO
|
||||
DATE_FORMAT_DATETIME
|
||||
DATE_FORMAT_UNIX
|
||||
DATE_FORMAT_ICAL
|
||||
|
||||
DATE_REGEX_ISO
|
||||
DATE_REGEX_DATETIME
|
||||
DATE_REGEX_LOOSE
|
||||
|
||||
date_format_date();
|
||||
date_t()
|
||||
date_short_formats();
|
||||
date_medium_formats();
|
||||
date_long_formats();
|
||||
date_format_patterns();
|
||||
|
||||
============================================================================
|
||||
Standardized ical parser and creator
|
||||
============================================================================
|
||||
The iCal parser is found in date_api_ical.inc, which is not included by default.
|
||||
Include that file if you want to use these functions:
|
||||
|
||||
Complete rewrite of ical imports to parse vevents, vlocations, valarms,
|
||||
and all kinds of timezone options and repeat rules for ical imports.
|
||||
The function now sticks to parsing the ical into an array that can be used
|
||||
in various ways. It no longer trys to convert timezones while parsing,
|
||||
instead a date_ical_date_format() function is provided that can be used to
|
||||
convert from the ical timezone to whatever timezone is desired in the
|
||||
results. Repeat rules are parsed into an array which other modules can
|
||||
manipulate however they like to create additional events from the results.
|
||||
|
||||
date_ical_export();
|
||||
date_ical_import();
|
||||
date_ical_date_format();
|
||||
|
||||
============================================================================
|
||||
Helpers for portable date SQL
|
||||
============================================================================
|
||||
The SQL functions are found in date_api_sql.inc, which is not included by default.
|
||||
Include that file if you want to use these functions:
|
||||
|
||||
date_sql();
|
||||
date_server_zone_adj();
|
||||
date_sql_concat();
|
||||
date_sql_pad();
|
||||
|
||||
============================================================================
|
||||
Date forms and validators
|
||||
============================================================================
|
||||
Reusable, configurable, self-validating FAPI date elements are found in
|
||||
date_api_elements.inc, which is not included by default. Include it
|
||||
if you want to use these elements. To use them, create a form element
|
||||
and set the '#type' to one of the following:
|
||||
|
||||
date_select
|
||||
The date_select element will create a collection of form elements, with a
|
||||
separate select or textfield for each date part. The whole collection will
|
||||
get re-formatted back into a date value of the requested type during validation.
|
||||
|
||||
date_text
|
||||
The date_text element will create a textfield that can contain a whole
|
||||
date or any part of a date as text. The user input value will be re-formatted
|
||||
back into a date value of the requested type during validation.
|
||||
|
||||
date_timezone
|
||||
The date_timezone element will create a drop-down selector to pick a
|
||||
timezone name.
|
||||
|
||||
The custom date elements require a few other pieces of information to work
|
||||
correctly, like #date_format and #date_type. See the internal documentation
|
||||
for more information.
|
||||
|
||||
============================================================================
|
||||
Date Popup Module
|
||||
============================================================================
|
||||
|
||||
A new module is included in the package that will enable a popup jQuery
|
||||
calendar date picker and timepicker in date and time fields.
|
||||
|
||||
It is implemented as a custom form element, so set '#type' to 'date_popup'
|
||||
to use this element. See the internal documentation for more information.
|
||||
|
||||
============================================================================
|
||||
Date Repeat API
|
||||
============================================================================
|
||||
|
||||
An API for repeating dates is available if installed. It can be used by
|
||||
other modules to create a form element that will allow users to select
|
||||
repeat rules and store those selections in an iCal RRULE string, and a
|
||||
calculation function that will parse the RRULE and return an array of dates
|
||||
that match those rules. The API is implemented in the Date module as a
|
||||
new date widget if the Date Repeat API is installed.
|
||||
|
||||
============================================================================
|
||||
Install file for dependent modules
|
||||
============================================================================
|
||||
|
||||
The following code is an example of what should go in the .install file for
|
||||
any module that uses the new Date API. This is needed to be sure the system
|
||||
is not using an earlier version of the API that didn't include all these new
|
||||
features. Testing for version '5.2' will pick up any version on or after the
|
||||
change to the new API.
|
||||
|
||||
/**
|
||||
* Implementation of hook_requirements().
|
||||
*/
|
||||
function calendar_requirements($phase) {
|
||||
$requirements = array();
|
||||
$t = get_t();
|
||||
|
||||
// This is the minimum required version for the Date API so that it will
|
||||
work with this module.
|
||||
$required_version = 5.2;
|
||||
|
||||
// Make sure the matching version of date_api is installed.
|
||||
// Use info instead of an error at install time since the problem may
|
||||
// just be that they were installed in the wrong order.
|
||||
switch ($phase) {
|
||||
case 'runtime':
|
||||
if (variable_get('date_api_version', 0) < $required_version) {
|
||||
$requirements['calendar_api_version'] = array(
|
||||
'title' => $t('Calendar requirements'),
|
||||
'value' => $t('The Calendar module requires a more current version
|
||||
of the Date API. Please check for a newer version.'),
|
||||
'severity' => REQUIREMENT_ERROR,
|
||||
);
|
||||
}
|
||||
break;
|
||||
case 'install':
|
||||
if (variable_get('date_api_version', 0) < $required_version) {
|
||||
$requirements['calendar_api_version'] = array(
|
||||
'title' => $t('Calendar requirements'),
|
||||
'value' => $t('The Calendar module requires the latest version
|
||||
of the Date API, be sure you are installing the latest versions
|
||||
of both modules.'),
|
||||
'severity' => REQUIREMENT_INFO,
|
||||
);
|
||||
}
|
||||
break;
|
||||
}
|
||||
return $requirements;
|
||||
}
|
||||
|
||||
/**
|
||||
* Implementation of hook_install().
|
||||
*/
|
||||
function calendar_install() {
|
||||
// Make sure this module loads after date_api.
|
||||
db_query("UPDATE {system} SET weight = 1 WHERE name = 'calendar'");
|
||||
}
|
||||
|
||||
/**
|
||||
* Implementation of hook_update().
|
||||
*/
|
||||
function calendar_update_5000() {
|
||||
$ret = array();
|
||||
$ret[] = update_sql("UPDATE {system} SET weight = 1 WHERE name = 'calendar'");
|
||||
return $ret;
|
||||
}
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
|
||||
Diff 2.x for Drupal 6.x
|
||||
-----------------------
|
||||
Diff enhances usage of node revisions by adding the following features:
|
||||
|
||||
- diff between node revisions on the 'Revisions' tab to view all the changes
|
||||
between any two revisions of a node
|
||||
- highlight changes inline while viewing a node to quickly see color-coded
|
||||
additions, changes, and deletions
|
||||
- preview changes as a diff before updating a node
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
Diff can be installed like any other Drupal module -- place it in
|
||||
the modules directory for your site and enable it on the `admin/build/modules`
|
||||
page.
|
||||
|
||||
Diff needs to be configured to be used with specific node types on your site.
|
||||
Enable any of diff's options on a content type's settings page (e.g.
|
||||
`admin/content/node-type/page`).
|
||||
|
||||
|
||||
Technical
|
||||
---------
|
||||
- Diff compares the raw data, not the filtered output, making it easier to see
|
||||
changes to HTML entities, etc.
|
||||
- The diff engine itself is a GPL'ed php diff engine from phpwiki.
|
||||
|
||||
API
|
||||
---
|
||||
This module offers `hook_diff()` which modules may use to inject their changes
|
||||
into the presentation of the diff. For example, this is used by
|
||||
`content.diff.inc` (see CCK), `upload.inc`, and `taxonomy.inc`.
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
- dww (Derek Wright)
|
||||
- moshe (Moshe Weitzman)
|
||||
- rötzi (Julian)
|
||||
- yhahn (Young Hahn)
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
|
||||
The External Links module is a very simple approach to adding icons to links
|
||||
to external websites or e-mail addresses. It is a purely JavaScript
|
||||
implementation, so the icons are only shown to users that have JavaScript
|
||||
enabled.
|
||||
|
||||
Fivestar was written by Nathan Haug. Built by Robots: http://www.lullabot.com
|
||||
|
||||
Install
|
||||
-------
|
||||
Simply instal External Links like you would any other module.
|
||||
|
||||
1) Copy the extlink folder to the modules folder in your installation.
|
||||
|
||||
2) Enable the module using Administer -> Modules (/admin/build/modules).
|
||||
|
||||
3) No additional configuration is necessary though you may fine-tune settings at
|
||||
Administer -> Site configuration -> External Links (/admin/settings/extlink).
|
||||
|
||||
A note about the CSS
|
||||
--------------------
|
||||
This module adds a CSS file that is only a few lines in length. You may choose
|
||||
to move this CSS to your theme to prevent the file from needing to be loaded
|
||||
separately. To do this:
|
||||
|
||||
1) Open the .info file for your theme, add this line of code to prevent
|
||||
the extlink.css file from loading:
|
||||
stylesheets[all][] = extlink.css
|
||||
2) Open the extlink.css file within the extlink directory and copy all the code
|
||||
from the file into your theme's style.css file.
|
||||
3) Copy the extlink.png and mailto.png files to your theme's directory.
|
||||
|
||||
Note that you DO NOT need to make a extlink.css file. Specifying the file in the
|
||||
info file is enough to tell Drupal not to load the original file.
|
||||
|
|
@ -1,84 +0,0 @@
|
|||
CONTENTS OF THIS FILE
|
||||
----------------------
|
||||
|
||||
* Introduction
|
||||
* Installation
|
||||
* Configuration
|
||||
* Known Issues
|
||||
- No FAQs appear after module upgrade
|
||||
- <p> tags appear in FAQ question text
|
||||
- Clicking on category links takes user to front page
|
||||
|
||||
|
||||
INTRODUCTION
|
||||
------------
|
||||
Maintainer: Stella Power (http://drupal.org/user/66894)
|
||||
|
||||
Documentation: http://drupal.org/node/129209
|
||||
|
||||
The Frequently Asked Questions (faq) module allows users with the 'administer
|
||||
faq' permission to create question and answer pairs which they want displayed on
|
||||
the 'faq' page. The 'faq' page is automatically generated from the FAQ nodes
|
||||
configured and the layout of this page can be modified on the settings page.
|
||||
Users will need the 'view faq' permission to view the 'faq' page.
|
||||
|
||||
There are 2 blocks included in this module, one shows a list of FAQ categories
|
||||
while the other can show a configurable number of recent FAQs added.
|
||||
|
||||
Note the function theme_faq_highlights(), which shows the last X recently
|
||||
created FAQs, used by one of the blocks, can also be called in a php-filtered
|
||||
node if desired.
|
||||
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
1. Copy faq folder to modules directory.
|
||||
2. At admin/build/modules enable the faq module.
|
||||
3. Enable permissions at admin/user/permissions.
|
||||
4. Configure the module at admin/settings/faq.
|
||||
|
||||
|
||||
UPGRADE NOTICE
|
||||
---------------
|
||||
When using categorized FAQ nodes, the disabling of the FAQ module causes the
|
||||
vocabulary to lose the association with the FAQ content type. This results in no
|
||||
FAQ nodes being displayed when you re-enable the FAQ module. Before opening an
|
||||
issue, please verify that this setting is still in place.
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
Once the module is activated, you can create your question and answer pairs by
|
||||
creating FAQ nodes (Create content >> FAQ). This allows you to edit the
|
||||
question and answer text. In addition, if the 'Taxonomy' module is enabled and
|
||||
there are some terms configured for the FAQ node type, it will also be possible
|
||||
to put the questions into different categories when editing.
|
||||
|
||||
|
||||
KNOWN ISSUES
|
||||
-------------
|
||||
No FAQs appear after module upgrade
|
||||
-----------------------------------
|
||||
When using categorized FAQ nodes, the disabling of the FAQ module causes the
|
||||
vocabulary to lose the association with the FAQ content type. This results in no
|
||||
FAQ nodes being displayed when you re-enable the FAQ module. Before opening an
|
||||
issue, please verify that this setting is still in place.
|
||||
|
||||
<p> tags appear in FAQ question text
|
||||
------------------------------------
|
||||
When using WYSIWYG editors, such as TinyMCE and FCKeditor, <p> and other HTML
|
||||
tags may appear in the displayed question text. This is because the faq title or
|
||||
question input box is a textarea and not a textfield, so the faq module can
|
||||
accommodate longer question texts. The p-tags come from the WYSIWYG editor used
|
||||
and not the FAQ module. This is because TinyMCE, and other WYSIWYG editors,
|
||||
attach themselves to all textareas on a given page. Details on how to prevent
|
||||
this can be found at http://drupal.org/node/294708
|
||||
|
||||
Clicking on category links takes user to front page
|
||||
---------------------------------------------------
|
||||
Reported for Drupal 5, unconfirmed for Drupal 6.
|
||||
Instead of being taken to the categorized faq page, the front page is displayed
|
||||
when the user clicks on a faq category. This is something to do with the
|
||||
pathauto module and can be easily fixed by doing a bulk update of paths for the
|
||||
faq vocabulary.
|
||||
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
|
||||
FileField provides an "File" field type to CCK. It provides many advantages over
|
||||
the Drupal core "Upload" module including:
|
||||
|
||||
* Per-field upload control (file extensions, file size).
|
||||
* Per-node upload size limits.
|
||||
* Multiple fields per content type.
|
||||
* Customizable paths for saving uploads (plus token support for dynamic paths).
|
||||
* Icons for uploaded file types.
|
||||
|
||||
FileField was written by Darrel Opry (dopry).
|
||||
Maintained by Nathan Haug (quicksketch) and Andrew Morton (drewish).
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
* Content
|
||||
|
||||
FileField also provides additional features when used with the following:
|
||||
|
||||
* ImageField (See an image preview during editing.)
|
||||
* Token (Generate dynamic paths when saving images.)
|
||||
* ImageCache (Create thumbnails of images on output.)
|
||||
|
||||
If your site is any larger than a personal blog, you should definitely install
|
||||
the following modules to increase the security and stability of your uploads.
|
||||
|
||||
* Transliteration (Convert unsafe characters to file system safe names.)
|
||||
* MimeDetect (Check the content of files to ensure they match the extension.)
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
1) Copy the filefield folder to the modules folder in your installation.
|
||||
|
||||
2) Enable the module using Administer -> Site building -> Modules
|
||||
(/admin/build/modules).
|
||||
|
||||
3) Create a new file field in through CCK's interface. Visit Administer ->
|
||||
Content management -> Content types (admin/content/types), then click
|
||||
Manage fields on the type you want to add an file upload field. Select
|
||||
"File" as the field type and "File" as the widget type to create a new
|
||||
field.
|
||||
|
||||
4) Upload files on the node form for the type that you set up.
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
|
||||
============================
|
||||
GeSHi Filter (Drupal Module)
|
||||
============================
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
The GeShi Filter is a Drupal module for syntax highlighting of pieces of
|
||||
source code. It implements a filter that formats and highlights the syntax of
|
||||
source code between for example <code>...</code>.
|
||||
|
||||
|
||||
DEPENDENCY
|
||||
----------
|
||||
This module requires the third-party library GeShi 1.0.x (Generic Syntax
|
||||
Highlighter, written by Nigel McNie) which can be found at
|
||||
http://qbnz.com/highlighter
|
||||
See installation procedure below for more information.
|
||||
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
1. Extract the GeSHi Filter module tarball and place the entire geshifilter
|
||||
directory into your Drupal modules directory.
|
||||
|
||||
2. Download the GeSHi library from
|
||||
http://sourceforge.net/projects/geshi/files/geshi
|
||||
Make sure you download a version of the branch 1.0.x and not a version
|
||||
from the branch 1.1.x (also described as geshi-dev), which is not yet
|
||||
supported by the GeSHi filter module.
|
||||
Place the entire extracted 'geshi' folder (which contains geshi.php)
|
||||
in the libraries directory (e.g. as libraries/geshi).
|
||||
|
||||
3. Enable this module as any other Drupal module by navigating to
|
||||
administer > site building > modules
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
1. The general GeSHi Filter settings can be found by navigating to:
|
||||
administer > site configuration > geshifilter.
|
||||
Set the path to the GeSHi library on that page, if it is not detected
|
||||
automatically already.
|
||||
2. Further configuration instructions can be found by following the
|
||||
"more help..." link at the top of that general settings page, which leads
|
||||
to www.example.com/?q=admin/help/geshifilter . This requires you have the
|
||||
'help' module enabled.
|
||||
|
||||
|
||||
USAGE
|
||||
-----
|
||||
The basic usage (with the default settings) is:
|
||||
<code language="java">
|
||||
for (int i; i<10; ++i) {
|
||||
dothisdothat(i);
|
||||
}
|
||||
</code>
|
||||
When language tags are enabled (like "<java>" for Java) you can also do
|
||||
<java>
|
||||
for (int i; i<10; ++i) {
|
||||
dothisdothat(i);
|
||||
}
|
||||
</java>
|
||||
More options and tricks can be found in the filter tips of the input format at
|
||||
www.example.com/?q=filter/tips .
|
||||
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
Original module by:
|
||||
Vincent Filby <vfilby at gmail dot com>
|
||||
|
||||
Drupal.org hosted version for Drupal 4.7:
|
||||
Vincent Filby <vfilby at gmail dot com>
|
||||
Michael Hutchinson (http://compsoc.dur.ac.uk/~mjh/contact)
|
||||
Damien Pitard <dpdev00 at gmail dot com>
|
||||
|
||||
Port to Drupal 5:
|
||||
rötzi (http://drupal.org/user/73064)
|
||||
Stefaan Lippens (http://drupal.org/user/41478)
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
|
||||
README.txt
|
||||
==========
|
||||
|
||||
********************************************************************
|
||||
This is i18n package 6.x, and works with Drupal 6.x
|
||||
********************************************************************
|
||||
WARNING: DO READ THE INSTALL FILE AND the ON-LINE HANDBOOK
|
||||
********************************************************************
|
||||
|
||||
This is a collection of modules providing multilingual features.
|
||||
These modules will build onto Drupal 6 core features enabling a full multilingual site
|
||||
|
||||
Up to date documentation will be kept on-line at http://drupal.org/node/133977
|
||||
|
||||
SimpleTest:
|
||||
-----------
|
||||
Tests for this module will run on SimpleTest 6.x-2.8 (old version).
|
||||
About this see http://drupal.org/node/584596
|
||||
|
||||
Additional Support
|
||||
=================
|
||||
For support, please create a support request for this module's project:
|
||||
http://drupal.org/project/i18n
|
||||
|
||||
Support questions by email to the module maintainer will be simply ignored. Use the issue tracker.
|
||||
|
||||
====================================================================
|
||||
Jose A. Reyero, drupal at reyero dot net, http://www.reyero.net
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
|
||||
README.txt
|
||||
==========
|
||||
Drupal module: i18nsync (Synchronization)
|
||||
|
||||
This module will handle content synchronization accross translations.
|
||||
|
||||
The available list of fields to synchronize will include standard node fields and cck fields.
|
||||
To have aditional fields, add the list in a variable in the settings.php file, like this:
|
||||
|
||||
// Available fields for synchronization, for all node types.
|
||||
$conf['i18nsync_fields_node'] = array(
|
||||
'field1' => t('Field 1 name'),
|
||||
'field2' => t('Field 2 name'),
|
||||
...
|
||||
);
|
||||
|
||||
// More fields for a specific content type 'nodetype' only.
|
||||
$conf['i18nsync_fields_node_nodetype'] = array(
|
||||
'field3' => t('Field 3 name'),
|
||||
...
|
||||
);
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
ImageAPI
|
||||
|
||||
A non writing image manipulation API for Drupal. This API is meant to be used in place of the API provided
|
||||
by image.inc. You probably do not need to install this module unless another module are you using requires
|
||||
it. It provides no new features to your drupal site. It only provides an API other modules can leverage.
|
||||
|
||||
Changes From image.inc API:
|
||||
- Images are objects.
|
||||
- Images are not written on each image operation and must be explicitly
|
||||
closed when processing is complete.
|
||||
- Multiple Image ToolKits can be used simultaneously. However, only the image
|
||||
toolkit and image was opened with can be used to process it. This is hidden
|
||||
in the imageapi layer.
|
||||
|
||||
API Quick Reference:
|
||||
imageapi_image_scale_and_crop($image, $width, $height)
|
||||
imageapi_image_scale($image, $width, $height, $upscale = FALSE)
|
||||
imageapi_image_resize($image, $width, $height)
|
||||
imageapi_image_rotate($image, $degrees, $bgcolor = 0x000000)
|
||||
imageapi_image_crop($image, $x, $y, $width, $height)
|
||||
imageapi_image_desaturate($image)
|
||||
imageapi_image_open($file, $toolkit = FALSE)
|
||||
imageapi_image_close($image, $destination)
|
||||
|
||||
$image is an image object returned from imageapi_image_open();
|
||||
|
||||
Expanding ImageAPI:
|
||||
|
||||
If you wish to expand on ImageAPI add a new wrapper function to
|
||||
imageapi.module. Do any common preprocessing for all underlying layers in the
|
||||
wrapper function, then invoke the driver. Pay heed to the function naming in
|
||||
ImageAPI and ImageAPI GD. If the toolkit changes the size of an image it must
|
||||
update the $image->info['width'] and $image->info['height'] variables. All
|
||||
ToolKit functions should return TRUE on success and FALSE on failure.
|
||||
|
||||
For more detailed documentation read imageapi.module.
|
||||
|
||||
-dopry
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
ImageCache is a dynamic image manipulation and cache tool. It allows you to
|
||||
create a namespace that corresponds to a set of image manipulation actions. It
|
||||
generates a derivative image the first time it is requested from a namespace
|
||||
until the namespace or the entire imagecache is flushed.
|
||||
|
||||
Getting Started:
|
||||
|
||||
1. Upload and enable both the ImageCache and ImageCache UI modules.
|
||||
|
||||
2. Go to Administer -> Site Building -> ImageCache. Click on the local task tab
|
||||
labeled "Add New Preset" to build a new set of image manipulation actions.
|
||||
|
||||
3. Enter a descriptive name of your choice (e.g. 'product_thumbnail') into the
|
||||
"Preset Namespace" box and click "Create New Preset".
|
||||
|
||||
4. Add actions to your preset that tell ImageCache how to manipulate the
|
||||
original image when it is rendered for display. Available actions include
|
||||
crop, scale, desaturate (grey scale), resize, and rotate. Multiple actions
|
||||
may be added to a preset.
|
||||
|
||||
5. Each action is configured in its own form, and the actions may be reordered
|
||||
from the preset's configuration form. If you need to make any changes to the
|
||||
order of actions in a preset, remember to click "Update Preset" when you're
|
||||
finished.
|
||||
|
||||
Viewing Manipulated Images:
|
||||
|
||||
Your modified image can be viewed by visiting a URL in this format:
|
||||
|
||||
http://example.com/files/imagecache/preset-name/files/image-name.jpg
|
||||
|
||||
For example, if your preset is named 'product_thumbnail' and your image is
|
||||
named 'green-widget.jpg', you could view your modified image at:
|
||||
|
||||
http://example.com/files/imagecache/product_thumbnail/files/green-widget...
|
||||
|
||||
NOTE: Each role that wishes to view the images generated by a
|
||||
particular preset must be given permission on the admin/user/permissions
|
||||
page.
|
||||
|
||||
ImageCache also defines a theme function that you can use in your modules and
|
||||
themes to automatically display a manipulated image. For example, to use the
|
||||
theme function in a .tpl.php file, add the following line where you would like
|
||||
the image to appear:
|
||||
|
||||
<?php
|
||||
print theme('imagecache', 'preset_namespace', $image_filepath, $alt, $title, $attributes);
|
||||
?>
|
||||
|
||||
Change 'preset_namespace' to the name of your imagecache preset and make sure
|
||||
that $image_filepath or some other variable contains the actual filepath to
|
||||
the image you would like to display.
|
||||
|
||||
$alt, $title and $attributes are optional parameters that specify ALT/TITLE
|
||||
text for the image element in the HTML or other attributes as specified in the
|
||||
$attributes array.
|
||||
|
||||
Using ImageCache with Contributed Modules:
|
||||
|
||||
ImageCache presets can be put to use in various other modules. For example, when
|
||||
using CCK with the Imagefield module, you can use the "Display fields" local
|
||||
task tab to choose a preset to apply to images in that field. Similarly, you
|
||||
can specify a preset when displaying images attached to nodes using Imagefield
|
||||
in a View through the Views UI.
|
||||
|
||||
For more information, refer to http://drupal.org/node/163561.
|
||||
|
||||
(Images, page names, and form field names may refer to previous versions of
|
||||
ImageCache, but the concepts are the same.)
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
|
||||
-- SUMMARY --
|
||||
|
||||
jQuery UI (http://ui.jquery.com/) is a set of cool widgets and effects that
|
||||
developers can use to add some pizazz to their modules.
|
||||
|
||||
This module is more-or-less a utility module that should simply be required by
|
||||
other modules that depend on jQuery UI being available. It doesn't do anything
|
||||
on its own.
|
||||
|
||||
For a full description of the module, visit the project page:
|
||||
http://drupal.org/project/jquery_ui
|
||||
|
||||
To submit bug reports and feature suggestions, or to track changes:
|
||||
http://drupal.org/project/issues/jquery_ui
|
||||
|
||||
|
||||
-- REQUIREMENTS --
|
||||
|
||||
* The jQuery UI library.
|
||||
|
||||
|
||||
-- INSTALLATION --
|
||||
|
||||
* Copy the jquery_ui module directory to your modules directory, so it
|
||||
is located in modules/jquery_ui/.
|
||||
|
||||
* Download the jQuery UI 1.6 release from:
|
||||
|
||||
http://code.google.com/p/jquery-ui/downloads/list?q=1.6
|
||||
|
||||
* Put the downloaded archive into the directory:
|
||||
|
||||
/libraries/jquery.ui-1.6.zip
|
||||
|
||||
* Extract the archive. This will create the following sub-directory:
|
||||
|
||||
/libraries/jquery.ui-1.6/
|
||||
|
||||
* Rename the sub-directory into "jquery.ui":
|
||||
|
||||
/libraries/jquery.ui/
|
||||
|
||||
so the actual jQuery UI JavaScript files are located in:
|
||||
|
||||
/libraries/jquery.ui/ui/*.js
|
||||
|
||||
* Enable the module at Administer >> Site building >> Modules.
|
||||
|
||||
|
||||
-- JQUERY UI 1.7 --
|
||||
|
||||
The jQuery UI module uses jQuery UI 1.6 because jQuery UI 1.7 requires at least
|
||||
jQuery 1.3, which is not shipped with Drupal 6. If you absolutely need to move
|
||||
to jQuery UI 1.7, you can get around this by doing the following:
|
||||
|
||||
* Download and install the corresponding jQuery Update module from:
|
||||
|
||||
http://drupal.org/project/jquery_update
|
||||
|
||||
* Download the latest jQuery UI 1.7 release from:
|
||||
|
||||
http://code.google.com/p/jquery-ui/downloads/list?q=1.7
|
||||
|
||||
* Put the downloaded archive into the directory:
|
||||
|
||||
/libraries/jquery.ui-1.7.zip
|
||||
|
||||
* Extract the archive. This will create the following sub-directory:
|
||||
|
||||
/libraries/jquery.ui-1.7/
|
||||
|
||||
* Rename the sub-directory into "jquery.ui":
|
||||
|
||||
/libraries/jquery.ui/
|
||||
|
||||
so the actual jQuery UI JavaScript files are located in:
|
||||
|
||||
/libraries/jquery.ui/ui/*.js
|
||||
|
||||
* Enable the module at Administer >> Site building >> Modules.
|
||||
|
||||
|
||||
-- API --
|
||||
|
||||
Developers who wish to use jQuery UI effects in their modules need only make
|
||||
the following changes:
|
||||
|
||||
* In your module's .info file, add the following line:
|
||||
|
||||
dependencies[] = jquery_ui
|
||||
|
||||
This will force users to have the jQuery UI module installed before they can
|
||||
enable your module.
|
||||
|
||||
* In your module, call the following function:
|
||||
|
||||
jquery_ui_add($files);
|
||||
|
||||
For example:
|
||||
|
||||
jquery_ui_add(array('ui.draggable', 'ui.droppable', 'ui.sortable'));
|
||||
|
||||
jquery_ui_add('ui.sortable'); // For a single file
|
||||
|
||||
See the contents of the jquery.ui-X.X sub-directory for a list of available
|
||||
files that may be included, and see http://ui.jquery.com/docs for details on
|
||||
how to use them. The required ui.core file is automatically included, as is
|
||||
effects.core if you include any effects files.
|
||||
|
||||
-- CONTACT --
|
||||
|
||||
Current maintainers:
|
||||
* Jeff Robbins (jjeff)
|
||||
* Angela Byron (webchick)
|
||||
* Addison Berry (add1sun)
|
||||
* Daniel F. Kudwien (sun) - http://drupal.org/user/54136
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
|
||||
Lexicon
|
||||
http://www.drupal.org/project/lexicon
|
||||
=====================================
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
A lexicon is a stock of terms used in a particular profession, subject or style; a vocabulary.
|
||||
The Lexicon module generates one or more Lexicon pages based on terms in taxonomies and optionally
|
||||
marks and links them in the content.
|
||||
|
||||
The Lexicon module is a branch of the Glossary module (http://www.drupal.org/project/glossary) that
|
||||
was changed to suit the needs of a project for the Dutch government. The main reason for the changes
|
||||
is compliancy with the web guidelines of the Dutch government (http://www.webguidelines.nl).
|
||||
|
||||
The main differences with the Glossary module are that the Lexicon module:
|
||||
|
||||
* Produces output that is valid W3C XHTML 1.0 Strict.
|
||||
* Enables showing lists of terms without marking the terms in content (this is still an option).
|
||||
You can choose which vocabularies act as Lexicons and you don't bind them to input filters.
|
||||
* Has configurable paths and titles for each Lexicon.
|
||||
* Optionally inserts a "go to top" link for each section on the Lexicon page.
|
||||
* Optionally "scroll to" internal links on the Lexicon page.
|
||||
|
||||
Development of this module is sponsored by Sogeti Netherlands (http://sogeti.doethetmetdrupal.nl).
|
||||
|
||||
|
||||
REQUIREMENTS
|
||||
------------
|
||||
Drupal 6.x
|
||||
Taxonomy
|
||||
|
||||
|
||||
INSTALLING
|
||||
----------
|
||||
1. To install the module copy the 'lexicon' folder to your modules directory.
|
||||
|
||||
2. Go to admin/build/modules. Enable the Lexicon module.
|
||||
Read more about installing modules at http://drupal.org/node/70151
|
||||
|
||||
|
||||
CONFIGURING AND USING
|
||||
---------------------
|
||||
1. Create a taxonomy vocabulary for each Lexicon.
|
||||
2. Go to admin/settings/lexicon.
|
||||
3. Select the created taxonomy vocabularies you want to use as Lexicons.
|
||||
4. Set the desired behavior of the Lexicon module and save the configuration.
|
||||
5. Configure the alphabar and save the configuration.
|
||||
6. Optionally set the paths and titles of the Lexicons and save the configuration.
|
||||
7. Optionally put the suggested menu-items in the right menu and activate them.
|
||||
|
||||
Have fun!
|
||||
|
|
@ -1,258 +0,0 @@
|
|||
CONTENTS OF THIS FILE
|
||||
----------------------
|
||||
|
||||
* Introduction
|
||||
* Installation
|
||||
* Adding Lightbox Functionality to your Images
|
||||
- No Grouping
|
||||
- With Grouping
|
||||
- Slideshow
|
||||
- Video
|
||||
- HTML Content Support
|
||||
- Inline Content Support
|
||||
- Turning the Image Caption into a Link
|
||||
* Keyboard Shortcuts
|
||||
* Translation of Configured Strings
|
||||
* Known Issues
|
||||
- Keyboard Shortcuts in Opera
|
||||
|
||||
|
||||
INTRODUCTION
|
||||
------------
|
||||
Maintainers:
|
||||
Stella Power (http://drupal.org/user/66894)
|
||||
Daniel F. Kudwien (http://drupal.org/user/54136)
|
||||
Mark Ashmead (http://drupal.org/user/52392)
|
||||
|
||||
Documentation: http://drupal.org/node/144469
|
||||
|
||||
Licensed under the GNU/GPL License
|
||||
Based on Lightbox v2.03.3 by Lokesh Dhakar
|
||||
<http://www.huddletogether.com/projects/lightbox2/>
|
||||
|
||||
Originally written to make use of the Prototype framework, and Script.acalo.us,
|
||||
now altered to use jQuery.
|
||||
|
||||
Permission has been granted to Mark Ashmead & other Drupal Lightbox2 module
|
||||
maintainers to distribute the original lightbox.js via Drupal.org under this
|
||||
license scheme. This file has been subsequently modified to make use of jQuery
|
||||
instead of prototype / script.acalo.us.
|
||||
|
||||
This module enables the use of lightbox2 which places images above your
|
||||
current page, not within. This frees you from the constraints of the layout,
|
||||
particularly column widths.
|
||||
|
||||
This module will include the lightbox CSS and JS files in your Drupal
|
||||
Installation without the need to edit the theme. The module comes with a
|
||||
Lightbox2 Lite option which does not use the jQuery libraries; it is therefore
|
||||
less likely to conflict with anything else.
|
||||
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
1. Copy lightbox2 folder to modules directory.
|
||||
2. At admin/build/modules enable the lightbox2 module.
|
||||
3. Enable permissions at admin/user/permissions.
|
||||
4. Configure the module at admin/settings/lightbox2.
|
||||
5. Modify your image links to open in a lightbox where necessary, see "Adding
|
||||
Lightbox Functionality to your Images' section below.
|
||||
6. If you need to play flv files, then you may need to install a FLV player.
|
||||
There are a number of freely available ones on the Internet, including
|
||||
http://www.jeroenwijering.com/
|
||||
|
||||
|
||||
ADDING LIGHTBOX FUNCTIONALITY TO YOUR IMAGES
|
||||
--------------------------------------------
|
||||
No Grouping
|
||||
===========
|
||||
Add rel="lightbox" attribute to any link tag to activate the lightbox.
|
||||
For example:
|
||||
<a href="images/image-1.jpg" rel="lightbox">image #1</a>
|
||||
<a href="images/image-1.jpg" rel="lightbox[][my caption]">image #1</a>
|
||||
|
||||
Optional: To show a caption either use the title attribute or put in the second
|
||||
set of [] of the rel attribute.
|
||||
|
||||
With Grouping
|
||||
==============
|
||||
If you have a set of related images that you would like to group, follow step
|
||||
one but additionally include a group name between square brackets in the rel
|
||||
attribute. For example:
|
||||
|
||||
<a href="images/image-1.jpg" rel="lightbox[roadtrip]">image #1</a>
|
||||
<a href="images/image-2.jpg" rel="lightbox[roadtrip][caption 2]">image #2</a>
|
||||
<a href="images/image-3.jpg" rel="lightbox[roadtrip][caption 3]">image #3</a>
|
||||
|
||||
No limits to the number of image sets per page or how many images are allowed
|
||||
in each set. Go nuts!
|
||||
|
||||
If you have a set of images that you would like to group together in a
|
||||
lightbox, but only wish for one of these images to be visible on your page, you
|
||||
can assign the "lightbox_hide_image" class to hide the additional images. For
|
||||
example:
|
||||
|
||||
<a href="images/image-1.jpg" rel="lightbox[roadtrip]">image #1</a>
|
||||
<a href="images/image-2.jpg" rel="lightbox[roadtrip]" class="lightbox_hide_image">image #2</a>
|
||||
<a href="images/image-3.jpg" rel="lightbox[roadtrip]" class="lightbox_hide_image">image #3</a>
|
||||
|
||||
Slideshow
|
||||
=========
|
||||
This is very similar to the grouping functionality described above. The only
|
||||
difference is that "rel" attribute should be set to "lightshow" instead of
|
||||
"lightbox". Using the same example as above, we could launch the images in a
|
||||
slideshow by doing:
|
||||
|
||||
<a href="images/image-1.jpg" rel="lightshow[roadtrip]">image #1</a>
|
||||
<a href="images/image-2.jpg" rel="lightshow[roadtrip][caption 2]">image #2</a>
|
||||
<a href="images/image-3.jpg" rel="lightshow[roadtrip][caption 3]">image #3</a>
|
||||
|
||||
Video
|
||||
=====
|
||||
It's possible to show video content in the lightbox. In this case the "rel"
|
||||
attribute should be set to "lightvideo". It's possible to group videos and
|
||||
to control the size of the lightbox by setting the 'width' and 'height
|
||||
properties. The properties can be configured like
|
||||
"lightvideo[group|width:300px; height: 200px;]" and
|
||||
"lightvideo[|width:300px; height: 200px;][my caption]". The properties should
|
||||
all be of the format "property: value;" - note the closing semi-colon. If no
|
||||
properties are set, then the default width and height of 400px will be used.
|
||||
See below for more detailed examples.
|
||||
|
||||
Basic example:
|
||||
<a href="http://video.google.com/videoplay?docid=1811233136844420765"
|
||||
rel="lightvideo">Google video example - default size</a>
|
||||
|
||||
Basic example with caption:
|
||||
<a href="http://video.google.com/videoplay?docid=1811233136844420765"
|
||||
rel="lightvideo[][my caption]">Google video example - default size</a>
|
||||
|
||||
Grouped example:
|
||||
<a href="http://video.google.com/videoplay?docid=29023498723974239479"
|
||||
rel="lightvideo[group][caption 1]">Grouped example 1</a>
|
||||
<a href="http://video.google.com/videoplay?docid=1811233136844420765"
|
||||
rel="lightvideo[group][caption 2]">Grouped example 2</a>
|
||||
|
||||
Controlling lightbox size example:
|
||||
<a href="http://video.google.com/videoplay?docid=1811233136844420765"
|
||||
rel="lightvideo[|width:400px; height:300px;][my caption]">Google video example -
|
||||
custom size</a>
|
||||
|
||||
Supported Video Formats
|
||||
asx, wmv, mov and swf videos should all be supported. A number of video
|
||||
providers are also supported, for example YouTube and Google Video. For full
|
||||
details on how to integrate these with lightbox, please see the online
|
||||
documentation.
|
||||
|
||||
HTML Content Support
|
||||
====================
|
||||
It's possible to show webpage content in the lightbox, using iframes. In this
|
||||
case the "rel" attribute should be set to "lightframe". Again it's possible to
|
||||
group the content, (e.g. "lightframe[search]") but in addition to that, it's
|
||||
possible to control some of the iframe properties. It's possible to set the
|
||||
'width', 'height' and 'scrolling' properties of the iframe. The properties are
|
||||
separated from the group name by a '|', for example
|
||||
"lightframe[search|width:100px;]" and
|
||||
"lightframe[search|width:100px;][my caption]". If no grouping is being used,
|
||||
then the '|' is still used and the format would be "lightframe[|width:100px;]".
|
||||
The properties should all be of the format "property: value;" - note the closing
|
||||
semi-colon. If no iframe properties are set, then the default width and height
|
||||
of 400px will be used. See below for more detailed examples.
|
||||
|
||||
Basic example:
|
||||
<a href="http://www.google.com" rel="lightframe">Search google</a>
|
||||
|
||||
Basic example with caption:
|
||||
<a href="http://www.google.com" rel="lightframe[][my caption]">Search google</a>
|
||||
|
||||
Grouped example:
|
||||
<a href="http://www.google.com" rel="lightframe[search]">Search google</a>
|
||||
<a href="http://www.yahoo.com" rel="lightframe[search][Search Yahoo]">Search yahoo</a>
|
||||
|
||||
Controlling iframe property example:
|
||||
<a href="http://www.google.com" rel="lightframe[|width:400px; height:300px; scrolling: auto;]">Search google</a>
|
||||
|
||||
Controlling iframe property when grouped example:
|
||||
<a href="http://www.google.com" rel="lightframe[search|width:400px; height:300px; scrolling: auto;][Search Google]">Search google</a>
|
||||
<a href="http://www.yahoo.com" rel="lightframe[search|width:400px; height:300px;]">Search yahoo</a>
|
||||
<a href="http://www.yahoo.com" rel="lightframe[search|width:400px; height:300px;][Search Yahoo]">Search yahoo</a>
|
||||
|
||||
Inline Content Support
|
||||
=======================
|
||||
It's possible to show HTML snippets in the lightbox, that is on the same domain.
|
||||
In this case the "rel" attribute should be set to "lightmodal". Again it's
|
||||
possible to group the content, (e.g. "lightmodal[search]") but in addition to
|
||||
that, it's possible to control some of the inline / modal properties. It's
|
||||
possible to set the 'width', 'height' and 'scrolling' properties of the inline
|
||||
content. The properties are separated from the group name by a '|', for example
|
||||
"lightmodal[search|width:100px;]" and
|
||||
"lightmodal[search|width:100px;][my caption]". If no grouping is being used,
|
||||
then the '|' is still used and the format would be "lightmodal[|width:100px;]".
|
||||
The properties should all be of the format "property: value;" - note the closing
|
||||
semi-colon. If no properties are set, then the default width and height of
|
||||
400px will be used. See below for more detailed examples.
|
||||
|
||||
Basic example:
|
||||
<a href="search.php" rel="lightmodal">Search</a>
|
||||
|
||||
Basic example with caption:
|
||||
<a href="search.php" rel="lightmodal[][my caption]">Search</a>
|
||||
|
||||
Grouped example:
|
||||
<a href="search.php" rel="lightmodal[search]">Search</a>
|
||||
<a href="search.php?status=1" rel="lightmodal[search][published]">Search published content</a>
|
||||
|
||||
Controlling modal property example:
|
||||
<a href="search.php" rel="lightmodal[|width:400px; height:300px; scrolling: auto;]">Search</a>
|
||||
|
||||
Controlling modal property when grouped example:
|
||||
<a href="search.php" rel="lightmodal[search|width:400px; height:300px; scrolling: auto;]">Search</a>
|
||||
<a href="search.php?status=1" rel="lightmodal[search|width:400px; height:300px;][Search published]">Search published content</a>
|
||||
<a href="search.php?status=0" rel="lightmodal[search|width:400px; height:300px;][Search Unpublished]">Search unpublished content</a>
|
||||
|
||||
|
||||
|
||||
Turning the Image Caption into a Link
|
||||
=====================================
|
||||
If you wish to turn the caption into a link, format your caption in the
|
||||
following way:
|
||||
|
||||
<a href="images/image-1.jpg" rel="lightbox[][<a href=\"http://www.yourlink.com\">Clicky Visit Link</a>'>image #1</a>
|
||||
|
||||
Note, the < and > characters have been changed to their HTML entities, and the "
|
||||
have been escaped.
|
||||
|
||||
|
||||
KEYBOARD SHORTCUTS
|
||||
------------------
|
||||
Not all of the default keyboard shortcuts work in the Opera browser, for example
|
||||
'z' for toggling the zoom and 'spacebar' for toggling play / pause in
|
||||
slideshows. This can be overcome by updating your shortcut settings in the
|
||||
Opera preferences editor.
|
||||
|
||||
The default keyboard shortcuts are listed below. You can override these on
|
||||
admin/settings/lightbox2.
|
||||
|
||||
Close : x, o, c, ESC
|
||||
Previous Image : p, Left Arrow
|
||||
Next Image : n, Right Arrow
|
||||
Toggle Zoom : z (not available in slideshow)
|
||||
Toggle Play / Pause : Spacebar (slideshow only)
|
||||
|
||||
|
||||
TRANSLATION OF CONFIGURED STRINGS
|
||||
----------------------------------
|
||||
In order to translate the lightbox2 configuration strings, such as the text for
|
||||
the "View Image Details" link and the image count, please install the i18n:
|
||||
internationalization module and follow the instructions at
|
||||
http://drupal.org/node/134002.
|
||||
|
||||
|
||||
KNOWN ISSUES
|
||||
------------
|
||||
|
||||
Keyboard Shortcuts in Opera
|
||||
---------------------------
|
||||
Not all of the default keyboard shortcuts work in the Opera browser, for example
|
||||
'z' for toggling the zoom and 'spacebar' for toggling play / pause in
|
||||
slideshows. This can be overcome by updating your shortcut settings in the
|
||||
Opera preferences editor.
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
|
||||
Link Checker
|
||||
------------
|
||||
|
||||
Installation:
|
||||
|
||||
1. Place the entire linkchecker folder into your modules directory.
|
||||
2. Go to Administer -> Site building -> Modules and enable the Link checker module.
|
||||
3. Go to Administer -> Site configuration -> Link checker and enable the node types to scan.
|
||||
4. Check all HTML tags that should be scanned.
|
||||
5. Adjust the other parameters if the defaults don't suit your needs.
|
||||
6. Save configuration
|
||||
7. Wait for cron to check all your links... this may take some time! :-)
|
||||
|
||||
If links are broken they appear under Administer -> Reports -> Broken links.
|
||||
|
||||
If not, make sure the cron is configured and running properly on your Drupal
|
||||
installation. The Link checker module also logs somewhat useful info about it's
|
||||
activity under Administer -> Reports -> Recent log entries.
|
||||
|
||||
|
||||
Required:
|
||||
|
||||
1. For internal URL extraction you need to make sure that Cron always get called
|
||||
with your real public site URL (for e.g. http://example.com/cron.php). Make
|
||||
sure it's never executed with http://localhost/cron.php or any other
|
||||
hostnames or ports, not available from public. Otherwise all links may be
|
||||
reported as broken and cannot verified as they should be.
|
||||
|
||||
To make sure it always works - it's required to configure the $base_url in
|
||||
the config settings.php with your public sites URL. Better safe than sorry!
|
||||
|
||||
|
||||
Known issues:
|
||||
|
||||
There are a lot of known issues in drupal_http_request(). These have been solved
|
||||
in HTTPRL. As a workaround it's recommended to use HTTPRL in linkchecker.
|
||||
|
||||
Issues list:
|
||||
|
||||
* #997648: drupal_http_request() always calls fread() one more time than necessary
|
||||
* #164365-12: drupal_http_request() does handle (invalid) non-absolute redirects
|
||||
* #205969-11: drupal_http_request() assumes presence of Reason-Phrase in response Status-Line
|
||||
* #371495: Error message from drupal_http_request() not UTF8 encoded
|
||||
* #193073-11: drupal_http_request - socket not initialized
|
||||
* #106506-8: drupal_http_request() does not handle 'chunked' responses - Make it support HTTP 1.1
|
||||
* #1096890-15: drupal_http_request should return error if reaches max allowed redirects
|
||||
* #875342-21: drupal_http_request() should pick up X-Drupal-Assertion-* HTTP headers
|
||||
* #965078-31: HTTP request checking is unreliable and should be removed in favor of watchdog() calls
|
||||
* #336367: HTTP client should protect commas when folding (compatibility with legacy HTTP/1.0)
|
||||
* #45338: log fsockopen errors to watchdog
|
||||
|
||||
|
||||
Other
|
||||
|
||||
* Drupal 6.14 only: A critical core bug has been introduced by #193383:
|
||||
set_time_limit: Centralize calls and prevent warnings and errors that stops
|
||||
link checker from verifying links. Apply the available D6 hotfix in #111 or
|
||||
update to Drupal 6.15+ to fix your installation.
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
|
||||
README file for the clone module for Drupal 6.x.
|
||||
|
||||
The clone module allows users to make a copy of an existing node and then edit
|
||||
that copy. The authorship is set to the current user, the menu and url aliases
|
||||
are reset, and the (localized) words "Clone of" are inserted into the title to
|
||||
remind you that you are not editing the original node.
|
||||
|
||||
Users with the "clone node" or "clone own nodes" permission can utilize this
|
||||
functionality. A new tab will appear on node pages with the word "Clone".
|
||||
Depending on the setting you choose there are two possible actions that will
|
||||
occur when you click that tab. Each of these is a different cloning "method".
|
||||
|
||||
The default method (used in the 5.x-2.x branch also) works by pre-populating the
|
||||
node form, rather than immediately saving a copy of the original node to the
|
||||
database. Thus, your node will not be saved until you hit "Submit" (just like
|
||||
if you went to node/add/x).
|
||||
|
||||
The alternative method that may be selected immediately saves the node (by
|
||||
default the user must confirm this action on a confirmation form). This may
|
||||
work better in some cases, but also means that the copied node may immediately
|
||||
show up on the front page or in RSS feeds even while you are editing it.
|
||||
|
||||
This module makes reasonable checks on access permissions. A user cannot clone
|
||||
a node unless they can use the input format of that node, and unless they have
|
||||
permission to create new nodes of that type based on a call to node_access().
|
||||
|
||||
Settings can be accessed at admin/settings/clone. On this page you can
|
||||
set whether the publishing options are reset when making a clone of a node.
|
||||
This is set for each node type individually.
|
||||
|
||||
This module seems to work with common node types, however YMMV, especially with
|
||||
nodes that have any sort of image or file attachments. In all cases, but
|
||||
especially if you are using a complex (CCK) or custom node type, you should
|
||||
evaluate this module on a test site with a copy of your database before
|
||||
attempting to use it on a live site. On the settings page you may choose
|
||||
node types to be omitted from the cloning mechanism - no users will be able
|
||||
to clone a node of an omitted type.
|
||||
|
||||
This module makes no attempt to respect field-level permissions set via
|
||||
CCK's Content Permissions module, or any other module that implements
|
||||
CCK field-level permissions hooks. You should test your configuration
|
||||
carefully or not allow access to the clone functionality for non-admins if
|
||||
you rely on field-level permissions for important site features.
|
||||
|
||||
To install this module, copy the folder with all the files to the modules
|
||||
directory of your Drupal installation and enable it at /admin/build/modules. Two
|
||||
new permissions are available, but there are no changes to the database
|
||||
structure.
|
||||
|
||||
Note: this module originally derived from code posted by Steve Ringwood
|
||||
(nevets@drupal) at http://drupal.org/node/73381#comment-137714
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
ABOUT THE NODE COMMENTS
|
||||
=======================
|
||||
|
||||
With this module comments can be full nodes. For every content type you can
|
||||
choose to use different content type as comment, or to continue using Drupal
|
||||
core comments.
|
||||
Thanks to this module, comments can have fields, revisions, taxonomy,
|
||||
uploaded files, access control and anything else that comes from the goodness
|
||||
of nodeapi.
|
||||
|
||||
Current maintainer: Andrey Tretyakov http://drupal.org/user/169459
|
||||
|
||||
REQUIREMENTS
|
||||
============
|
||||
|
||||
Views module.
|
||||
|
||||
USAGE AND TECHNICAL DETAILS
|
||||
===========================
|
||||
|
||||
Node Comments module has settings page at admin/settings/nodecomment. There you
|
||||
can get overview of your content types and their Node Comment settings.
|
||||
The module also uses Comment module settings, configured per content type.
|
||||
|
||||
Comment types can have own comments. For example, a site can have
|
||||
products, commented by reviews, commented by comments.
|
||||
|
||||
Comment types can be enabled to work as "content", meaning they will have own
|
||||
pages, full node titles (independently from the comment settings) and generally
|
||||
behave as content. The only requirement currently is they must be added in
|
||||
comment context, i.e. via "Add new <type>" link for their target node.
|
||||
|
||||
Node Comments displays comments using "nodecomments" view. You can configure
|
||||
the view to tweak some options, but "Nodecomments" (second) display is always
|
||||
used, and you can switch display style (e.g. set it to "table") only when node
|
||||
comments are configured as flat in content type configuration. In threaded mode
|
||||
Node Comments module forces usage of own display style.
|
||||
|
||||
When deleting a node with node comments, or a node comment, child node comments
|
||||
will be automatically deleted even if the user performing the delete doesn't
|
||||
have delete permission for them. This may be surprise for you if you previously
|
||||
used 2.x branch. This is needed not to leave orphan nodes in the database and is
|
||||
generally in line with the core Comment module logics.
|
||||
This behavior can be changed programmatically (see Node Comments API).
|
||||
|
||||
To theme the node comments, use general node templates. There are some tricks,
|
||||
in terms of theming, though.
|
||||
First, because we generally repeat comment module stuff, we use "comment-123"
|
||||
anchors (where 123 is node id). You must add these anchors to your nodecomment
|
||||
templates for consistent scrolling.
|
||||
When previewing a nodecomment on the same page with the thread, the module
|
||||
will try to scroll to preview zone using "#preview" anchor. This
|
||||
anchor is missing from the original theme_node_preview() function so you need
|
||||
to add it using theme override.
|
||||
|
||||
KNOWN ISSUES
|
||||
============
|
||||
|
||||
This module may consume more resources and run slower than the core Comment
|
||||
module. To increase performance there is special Views caching plugin which
|
||||
caches the view output (a list of node comments). It can cause problems with
|
||||
modules expecting to modify node output in the list dynamically.
|
||||
There are 2 solutions to this problem:
|
||||
- the caching can be disabled via Views UI
|
||||
- using hook_views_post_render() one can insert dynamic values in the cached
|
||||
output. This is similar to what Node Comments module itself does.
|
||||
|
||||
To render node comments, the module overrides node view menu callback. This can
|
||||
conflict with other modules doing the same. This is a limitation of Drupal: only
|
||||
one function can process menu item. To deal with this problem, you can use
|
||||
Panels module and output combined data from both Node Comments and conflicting
|
||||
module. For more information, see http://drupal.org/node/477518.
|
||||
|
||||
Unlike 2.x branch, 3.x doesn't have comment conversion tool anymore. It had too
|
||||
many bugs and could lose data. Current maintainer is not comfortable supporting
|
||||
it. It can be revived as a separate module anytime, if someone is willing to do
|
||||
that.
|
||||
This means that changing comment type when comments of that type already exist
|
||||
can turn them into orphans, and break the database consistency. You are STRONGLY
|
||||
recommended to configure comment types only once.
|
||||
|
||||
For efficiency and reliability the module uses MySQL-only upsert (merge)
|
||||
queries. If you want to make the module work with Postgres, submit a patch.
|
||||
|
||||
COMPATIBILITY WITH COMMENT MODULE
|
||||
=================================
|
||||
|
||||
Previous branches of Node Comments had various issues with Comment module:
|
||||
- 1.x branch was not compatible at all
|
||||
- 2.x branch had many hacks, resulting in lots of bugs and compatibility issues
|
||||
with other contributed modules
|
||||
|
||||
3.x branch has exactly one hack: when loading a node with node comments enabled,
|
||||
it moves "commentability" setting to own variable, so other modules
|
||||
think the node can't be commented using Drupal core comments. When saving
|
||||
the node, Node Comments restores that setting. Thus we fully re-use Comment
|
||||
module default "commentability" setting and per-node "commentability" setting.
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
|
||||
Password policy
|
||||
==========================================
|
||||
This module provides a way to specify a certain level of password
|
||||
complexity (aka. "password hardening") for user passwords on a
|
||||
system by defining a password policy.
|
||||
|
||||
A password policy can be defined with a set of constraints which
|
||||
must be met before a user password change will be accepted. Each
|
||||
constraint has a parameter allowing for the minimum number of valid
|
||||
conditions which must be met before the constraint is satisfied.
|
||||
|
||||
Example: an uppercase constraint (with a parameter of 2) and a
|
||||
digit constraint (with a parameter of 4) means that a user password
|
||||
must have at least 2 uppercase letters and at least 4 digits for it
|
||||
to be accepted.
|
||||
|
||||
Current constraints include:
|
||||
|
||||
* Digit constraint
|
||||
* Letter constraint
|
||||
* Letter/Digit constraint (Alphanumeric)
|
||||
* Length constraint
|
||||
* Uppercase constraint
|
||||
* Lowercase constraint
|
||||
* Punctuation constraint
|
||||
* Character types constraint (allows the administrator to set the minimum
|
||||
number of character types required, but without actually dictating which
|
||||
ones must be used. Example - Windows requires any 3 (user's choice) of
|
||||
uppercase, lowercase, numbers, or punctuation.
|
||||
* History constraint (checks hashed password against a
|
||||
collection of users previous hashed passwords looking for
|
||||
recent duplicates)
|
||||
* Username constraint
|
||||
|
||||
The module also implements configurable password expiration features:
|
||||
|
||||
* When a password is not changed for a certain amount of time the user will
|
||||
be forced to change their password on next login.
|
||||
* Optionally, the user will also be blocked upon password expiration.
|
||||
* Expiration of passwords can begin after expiration time from enabling
|
||||
the policy or immediately all users with passwords older than expiration
|
||||
time will be blocked (retroactive behavior).
|
||||
* Expiration notifications (warnings) are mailed to the users several times
|
||||
(configurable) before the password expires.
|
||||
* Warning e-mail message's subject and body are configurable.
|
||||
|
||||
Limitations
|
||||
==========================================
|
||||
Password policies only apply to passwords set via user forms in the web
|
||||
interface. Passwords changed by other means (Drush, web services, etc.) will
|
||||
not be subject to password policy constraints. Please see the following issue
|
||||
if you would like to contribute to removing this limitation:
|
||||
|
||||
https://www.drupal.org/node/2451159
|
||||
|
||||
Security note
|
||||
==========================================
|
||||
Enforcing tough policy is only good from a technical standpoint. You are
|
||||
likely to end up with a situation where the users write down their super
|
||||
secure and super impossible to remember passwords. Help texts on how can
|
||||
you memorize such things (like shifting a word one row up the keyboard
|
||||
and so on). You should have separate company policy that deters users from
|
||||
writing passwords on a Post-it on the backside of their keyboard.
|
||||
|
||||
Consider a company policy to use strong password generator tools like
|
||||
http://supergenpass.com/ or 1Password on MacOS.
|
||||
|
||||
Requirements
|
||||
==========================================
|
||||
Drupal 6.x
|
||||
MySQL 5.0.3 or something else which supports varchar > 255
|
||||
|
||||
Credits
|
||||
==========================================
|
||||
Drupal 4.7 version was written by David Ayre <drupal at ayre dot ca>
|
||||
Refactored and maintained by Miglius Alaburda <miglius at gmail dot com>
|
||||
Sponsored by Bryght, SPAWAR, McDean
|
||||
|
|
@ -1,173 +0,0 @@
|
|||
|
||||
DESCRIPTION
|
||||
===========
|
||||
This module completes the job left unfinished by Drupal's Path module.
|
||||
The module extends Drupal's path alias system by automatically applying
|
||||
user-friendly page aliases not only to the base URL, e.g. "about-us" (for
|
||||
"node/123"), but also to any of the common extensions of the base URL, e.g.
|
||||
"about-us/edit", "about-us/track", "about-us/revisions*" etc.
|
||||
|
||||
The extended aliases may also be used when specifying visibility control for
|
||||
blocks (e.g. "about-us*"), or in fact anywhere where you are prompted to
|
||||
specify pages to include or exclude.
|
||||
NOTE: It is for this feature that you need to follow the INSTALLATION
|
||||
instructions below. If don't care about this feature just enable the module at
|
||||
Administer >> Site building >> Modules and you're away.
|
||||
|
||||
Requiring no configuration, the module then makes sure that these user-friendly
|
||||
(and SEO-friendly) aliases are shown everywhere, replacing their system-
|
||||
generated equivalents, whether it's in the browser address bar or on
|
||||
the page itself. Examples are the Edit, Track, Revisions etc. tabs, the page
|
||||
statistics pages as well as any other links on your pages. No more ugly URLs
|
||||
like node/123/revisons/456/view or user/7/track.
|
||||
|
||||
All of this makes everyone's user experience just that little more convenient
|
||||
across all pages of your site.
|
||||
|
||||
INSTALLATION
|
||||
============
|
||||
0 If you have a compiled PECL runkit extension file (see notes at the bottom
|
||||
of this file), put it in the appropriate /extension directory.
|
||||
The runkit is not mandatory, so if you don't have a runkit.so or
|
||||
php_runkit.dll file, simply continue at step 1.
|
||||
|
||||
With your runkit in place proceed with either step a) or b) (preferred).
|
||||
|
||||
a) In file path_alias_xt, find the line //dl('runkit.so'). Remove the
|
||||
leading double slashes.
|
||||
Or
|
||||
b) Edit your php.ini. You can use drupal page /admin/reports/status/php to
|
||||
locate the "Configuration File Path". It's near the top of the page and
|
||||
usually equals something like /etc/php5/apache2.
|
||||
Add this line to the other extension lines in your php.ini:
|
||||
|
||||
extension = runkit.so
|
||||
|
||||
Note: for Windows the correct line is "extension = php_runkit.dll".
|
||||
By the way, while you're down there, check that your php.ini has:
|
||||
|
||||
error_reporting = E_ALL
|
||||
display_errors = On
|
||||
|
||||
This ensures that if any "white screens of death" occur, these will at
|
||||
least display a clue as to what's going on.
|
||||
|
||||
1. As with any other module, uncompress the tar-ball, path_alias_xt.tar.gz, into
|
||||
the "modules" subdirectory.
|
||||
2. Just in case, if you are installing to a live site, put the site off-line at
|
||||
Site configuration >> Site maintenance. You will only need about 60 seconds.
|
||||
3. Visit Site building >> Modules to enable the path_alias_xt module. Press
|
||||
"Save configuration".
|
||||
At this point your extended path aliases should have started to work for
|
||||
the majority of pages.
|
||||
However to get block visibility wildcards to work you need to complete
|
||||
either step 4a or 4b.
|
||||
|
||||
4a.If you have placed the runkit extension in the /extension directory and have
|
||||
edited your php.ini as per step 0b, you now restart your Drupal stack (or
|
||||
just Apache). If you did step 0a, no restart should be necessary.
|
||||
In either case, verify the runkit has been loaded at /admin/reports/status or
|
||||
at /admin/reports/status/php.
|
||||
When you scroll down the page you should see a section on runkit.
|
||||
4b.If you did not install the runkit extension file, you need to edit file
|
||||
"inlcudes/path.inc" using any plain text editor. In this file find the
|
||||
following line (#109 ?):
|
||||
|
||||
function drupal_get_path_alias($path, $path_language = '') {
|
||||
|
||||
Immediately below this line insert:
|
||||
|
||||
if (module_exists('path_alias_xt')) {
|
||||
return path_alias_xt_get_path_alias($path, $path_language);
|
||||
}
|
||||
|
||||
5. Put your site back on line at Site configuration >> Site maintenance.
|
||||
|
||||
CONFIGURATION
|
||||
=============
|
||||
None, you're done.
|
||||
|
||||
USAGE
|
||||
======
|
||||
Users create and use aliases for nodes as per normal, i.e. via the
|
||||
"URL path settings" fieldset on the Edit form. Or if you have PathAuto enabled
|
||||
URL aliases for the base page are created automatically.
|
||||
|
||||
Let's say someone introduced "about-us" as an alias for some node, say the
|
||||
system assigned node/123 to it. Whenever specifying page filters, for instance
|
||||
on the page-specific visibility settings of a block's configuration page,
|
||||
Site building >> Blocks >> configure, users may now type "about-us/edit",
|
||||
"*about-us*" etc. rather than node/123/edit, node/123* etc.
|
||||
|
||||
When the system displays pages of the form "node/123/..", "about-us/.." will
|
||||
be shown in the address bar instead. Plus all tabs and links on your pages are
|
||||
human-readable and SEO-friendly to boot!
|
||||
|
||||
UNINSTALL
|
||||
=========
|
||||
You may disable path_alias_xt at any time, without reverting the change you've
|
||||
made to path.inc, as that code auto-detects whether path_alias_xt is enabled or
|
||||
not.
|
||||
If you used the PECL runkit, you may want to put a semi-colon in front of the
|
||||
"extension = runkit.so" line in your php.ini, so that the kit will no longer be
|
||||
loaded.
|
||||
|
||||
CAVEATS
|
||||
=======
|
||||
You may run into difficulties when using this module in combination with a
|
||||
module that also implements custom_url_rewrite_inbound(). There aren't many
|
||||
around though, so on the vast majority of systems everything should be fine.
|
||||
A generic solution would probably involve the url_alter module, which means an
|
||||
extra dependency as well as more complex code. I like to keep things simple.
|
||||
You should be able to use Extended Path Aliases with Domain Access, as this
|
||||
module only implements custom_url_rewrite_outbound(), which is not required by
|
||||
path_alias_xt.
|
||||
|
||||
HOW TO OBTAIN THE PECL RUNKIT EXTENSION LIBRARY
|
||||
===============================================
|
||||
There are some copies of runkit.so and php_runkit.dll lying about on the
|
||||
internet, but most of them are old (i.e. version 0.9) and will NOT work with
|
||||
PHP 5.2.x or 5.3.x. You're likely to get a white screen of death.
|
||||
Check this issue for a PECL runkit library for your OS: http://drupal.org/node/760758
|
||||
If there isn't one suitable for your system, you may have to compile the PECL
|
||||
runkit (version 1.0) yourself, see below.
|
||||
|
||||
Mac/Unix/Linux
|
||||
--------------
|
||||
Mac users, in order for the following commands to work sign up as an Apple
|
||||
Developer (free at http://developer.apple.com/programs/register), then download
|
||||
and install the Xcode developer package comptabile with your OS. In addition, if
|
||||
you use a MAMP stack, you may also want to point it to the Xcode header files:
|
||||
|
||||
$ ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/include /Applications/MAMP/bin/php5/include
|
||||
|
||||
If not on a Mac make sure that the following commands exist on your system:
|
||||
svn, php, phpize.
|
||||
If not, you can install them with a command like the following (for Ubuntu) or
|
||||
similar:
|
||||
|
||||
$ sudo apt-get install subversion php5-cli php5-dev
|
||||
|
||||
Now make sure you're machine is connected to the internet. Then:
|
||||
|
||||
$ svn co http://svn.php.net/repository/pecl/runkit/trunk runkit
|
||||
$ cd runkit
|
||||
$ phpize
|
||||
$ ./configure
|
||||
$ make
|
||||
|
||||
For the final step, on MAMP:
|
||||
$ cp modules/runkit.so /Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20060613 (or similar number)
|
||||
|
||||
Whereas on most other flavours of Unix/Linux you'd go:
|
||||
$ sudo make install
|
||||
|
||||
This *should* place runkit.so in the correct extension directory, usually
|
||||
something like /usr/lib/php5/20060613. The "extension_dir" directive
|
||||
should match this by default. You can verify the active "extension_dir" on the
|
||||
/admin/reports/status/php page. If it doesn't match, edit your php.ini.
|
||||
|
||||
Windows
|
||||
-------
|
||||
To compile a PECL extension on Windows see for instance:
|
||||
http://blog.renangoncalves.com/2010/01/15/how-to-compile-a-pecl-extension-on-windows
|
||||
|
|
@ -1,94 +0,0 @@
|
|||
Please read this file and also the INSTALL.txt.
|
||||
They contain answers to many common questions.
|
||||
If you are developing for this module, the API.txt may be interesting.
|
||||
If you are upgrading, check the CHANGELOG.txt for major changes.
|
||||
|
||||
**Description:
|
||||
The Pathauto module provides support functions for other modules to
|
||||
automatically generate aliases based on appropriate criteria, with a
|
||||
central settings path for site administrators.
|
||||
|
||||
Implementations are provided for core content types: nodes, taxonomy
|
||||
terms, and users (including blogs and tracker pages).
|
||||
|
||||
Pathauto also provides a way to delete large numbers of aliases. This feature
|
||||
is available at Administer > Site building > URL aliases > Delete aliases
|
||||
|
||||
**Benefits:
|
||||
Besides making the page address more reflective of its content than
|
||||
"node/138", it's important to know that modern search engines give
|
||||
heavy weight to search terms which appear in a page's URL. By
|
||||
automatically using keywords based directly on the page content in the URL,
|
||||
relevant search engine hits for your page can be significantly
|
||||
enhanced.
|
||||
|
||||
**Installation AND Upgrades:
|
||||
See the INSTALL.txt file.
|
||||
|
||||
**Notices:
|
||||
Pathauto just adds URL aliases to nodes, users, and taxonomy terms. Because
|
||||
it's an alias, the standard Drupal URL (for example node/123 or
|
||||
taxonomy/term/1) will still function as normal. If you have external links
|
||||
to your site pointing to standard Drupal URLs, or hardcoded links in a module,
|
||||
template, node or menu which point to standard Drupal URLs it will bypass the
|
||||
alias set by Pathauto.
|
||||
|
||||
There are reasons you might not want two URLs for the same content on your
|
||||
site. If this applies to you, please note that you will need to update any
|
||||
hard coded links in your nodes or blocks.
|
||||
|
||||
If you use the "system path" (i.e. node/10) for menu items and settings like
|
||||
that, Drupal will replace it with the url_alias.
|
||||
|
||||
For external links, you might want to consider the Path Redirect or
|
||||
Global Redirect modules, which allow you to set forwarding either per item or
|
||||
across the site to your aliased URLs.
|
||||
|
||||
URLs (not) Getting Replaced With Aliases:
|
||||
Please bear in mind that only URLs passed through Drupal's l() or url()
|
||||
functions will be replaced with their aliases during page output. If a module
|
||||
or your template contains hardcoded links, such as 'href="node/$node->nid"'
|
||||
those won't get replaced with their corresponding aliases. Use the
|
||||
Drupal API instead:
|
||||
|
||||
* 'href="'. url("node/$node->nid") .'"' or
|
||||
* l("Your link title", "node/$node->nid")
|
||||
|
||||
See http://api.drupal.org/api/HEAD/function/url and
|
||||
http://api.drupal.org/api/HEAD/function/l for more information.
|
||||
|
||||
** Disabling Pathauto for a specific node type (or taxonomy)
|
||||
When the pattern for a node type is left blank, the default pattern will be
|
||||
used. But if the default pattern is also blank, Pathauto will be disabled
|
||||
for that node type.
|
||||
|
||||
** Bulk Updates Must be Run Multiple Times:
|
||||
As of 5.x-2.x Pathauto now performs bulk updates in a manner which is more
|
||||
likely to succeed on large sites. The drawback is that it needs to be run
|
||||
multiple times. If you want to reduce the number of times that you need to
|
||||
run Pathauto you can increase the "Maximum number of objects to alias in a
|
||||
bulk update:" setting under General Settings.
|
||||
|
||||
**WYSIWYG Conflicts - FCKEditor, TinyMCE, etc.
|
||||
If you use a WYSIWYG editor, please disable it for the Pathauto admin page.
|
||||
Failure to do so may cause errors about "preg_replace" problems due to the <p>
|
||||
tag being added to the "strings to replace". See http://drupal.org/node/175772
|
||||
|
||||
**Credits:
|
||||
The original module combined the functionality of Mike Ryan's autopath with
|
||||
Tommy Sundstrom's path_automatic.
|
||||
|
||||
Significant enhancements were contributed by jdmquin @ www.bcdems.net.
|
||||
|
||||
Matt England added the tracker support.
|
||||
|
||||
Other suggestions and patches contributed by the Drupal community.
|
||||
|
||||
Current maintainers:
|
||||
Greg Knaddison - http://growingventuresolutions.com
|
||||
Mike Ryan - http://mikeryan.name
|
||||
Frederik 'Freso' S. Olesen - http://freso.dk
|
||||
|
||||
**Changes:
|
||||
See the CHANGELOG.txt file.
|
||||
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
Pathologic
|
||||
----------
|
||||
|
||||
Project Page:
|
||||
http://drupal.org/project/pathologic
|
||||
|
||||
By Garrett Albright
|
||||
http://drupal.org/user/191212
|
||||
Email: albright (at) abweb [dot] us
|
||||
AIM: AlbrightGuy - ICQ: 150670553 - IRC: Albright
|
||||
|
||||
Installation & Configuration
|
||||
----------------------------
|
||||
|
||||
For full installation and configuration instructions, please see this page in the Drupal manual:
|
||||
http://drupal.org/node/257026
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
|
||||
This module implements secure password hashes using backported code from
|
||||
Drupal 7, which is the outcome of http://drupal.org/node/29706.
|
||||
|
||||
This module requires PHP 5.2.4 as a minimum version (the same as Drupal 7).
|
||||
|
||||
IMPORTANT - this module cannot be disabled except via SQL or upgrading to
|
||||
Drupal 7. Disabling will mean all users will have to login via password-reset
|
||||
links.
|
||||
|
||||
Upgrading to Drupal 7 should be seamless as long as the core version is
|
||||
>= 7.9. That is the first release that includes the fix at
|
||||
http://drupal.org/node/1205138. The hashes stored in the {users} table
|
||||
by this module are fully compatible with the Drupal 7 password system.
|
||||
|
||||
The default Drupal 6 and before password hashes are insecure. MD5 has
|
||||
long been known to be crackable, and we should not be storing passwords
|
||||
using this.
|
||||
|
||||
There has been a long discussion about this. See http://drupal.org/node/29706
|
||||
and http://drupal.org/node/1201444 for in-depth discussions. Do not post
|
||||
issues about anything already discussed there.
|
||||
|
|
@ -1,127 +0,0 @@
|
|||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This module allows you to generate the following printer-friendly versions
|
||||
of any node:
|
||||
|
||||
* Web page printer-friendly version (at www.example.com/print/nid)
|
||||
* PDF version (at www.example.com/printpdf/nid)
|
||||
* Send by-email (at www.example.com/printmail/nid)
|
||||
|
||||
where nid is the node id of content to render.
|
||||
|
||||
A link is inserted in the each node (configurable in the content type
|
||||
settings), that opens a version of the page with no sidebars, search boxes,
|
||||
navigation pages, etc.
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
Follow the instructions in the provided INSTALL.txt file.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
- There are several settings that can be configured in the following places:
|
||||
|
||||
Administer > Site building > Modules (admin/build/modules)
|
||||
Enable or disable the module. (default: disabled)
|
||||
|
||||
Administer > User management > Permissions (admin/user/permissions)
|
||||
Under print module:
|
||||
access print: Enable access to the PF page and display of the PF link in
|
||||
other pages. (default: disabled)
|
||||
administer print: Enable access to the module settings page. (default:
|
||||
disabled)
|
||||
|
||||
Administer > Content management > Content types (admin/content/types)
|
||||
For each content type it is possible to enable or disable the PF link
|
||||
via the "Show printer-friendly version link" checkbox. (default:
|
||||
enabled)
|
||||
It is also possible to enable or disable the PF link in individual
|
||||
comments via the "Show printer-friendly version link in individual
|
||||
comments" checkbox. (default: disabled)
|
||||
|
||||
Administer > Site configuration > Printer-friendly (admin/settings/print)
|
||||
This is where all the module-specific configuration options can be set.
|
||||
|
||||
- To modify the template of printer friendly pages, simply edit the
|
||||
print.tpl.php or the css/print.css files.
|
||||
|
||||
- It is possible to set per-content-type and/or theme-specific templates
|
||||
which are searched for in the following order:
|
||||
1. print_[format].node-[type].tpl.php in the theme directory
|
||||
2. print_[format].node-[type].tpl.php in the module directory
|
||||
3. print_[format].tpl.php in the theme directory
|
||||
4. print_[format].tpl.php in the module directory
|
||||
5. print.node-[type].tpl.php in the theme directory
|
||||
6. print.node-[type].tpl.php in the module directory
|
||||
7. print.tpl.php in the theme directory
|
||||
8. print.tpl.php in the module directory (supplied by the module)
|
||||
|
||||
format is either html, mail or pdf, and type is Drupal's node type (e.g.
|
||||
page, story, etc.)
|
||||
|
||||
API
|
||||
---
|
||||
|
||||
print_insert_link(), print_mail_insert_link(), print_pdf_insert_link()
|
||||
|
||||
The *_insert_link functions are available to content developers that prefer
|
||||
to place the printer-friendly link in a custom location. It is advisable to
|
||||
disable the regular Printer-friendly link so that it is not shown in both
|
||||
locations.
|
||||
|
||||
Calling the function like this:
|
||||
|
||||
print_insert_link()
|
||||
|
||||
will return the HTML for a link pointing to a Printer-friendly version of
|
||||
the current page.
|
||||
|
||||
It is also possible to specify the link to the page yourself:
|
||||
|
||||
print_insert_link("print/42")
|
||||
|
||||
will return the HTML pointing to the printer-friendly version of node 42.
|
||||
|
||||
THEMEABLE FUNCTIONS
|
||||
-------------------
|
||||
|
||||
The following themeable functions are defined:
|
||||
|
||||
* theme_print_format_link()
|
||||
* theme_print_mail_format_link()
|
||||
* theme_print_pdf_format_link()
|
||||
Returns an array of formatted attributes for the Printer-friendly
|
||||
link.
|
||||
|
||||
* print_pdf_dompdf_footer($html)
|
||||
Format the dompdf footer contents
|
||||
|
||||
* print_pdf_tcpdf_header($pdf, $html, $font)
|
||||
Format the TCPDF header
|
||||
|
||||
* print_pdf_tcpdf_page($pdf)
|
||||
Format the TCPDF page settings (margins, etc)
|
||||
|
||||
* print_pdf_tcpdf_content($pdf, $html, $font)
|
||||
Format the TCPDF page content
|
||||
|
||||
* print_pdf_tcpdf_footer($pdf, $html, $font)
|
||||
Format the TCPDF footer contents
|
||||
|
||||
* print_pdf_tcpdf_footer2($pdf)
|
||||
Format the TCPDF footer layout
|
||||
|
||||
MORE INFORMATION
|
||||
----------------
|
||||
|
||||
For more information, consult the modules' documentation at
|
||||
http://drupal.org/node/190171.
|
||||
|
||||
ACKNOWLEDGMENTS
|
||||
---------------
|
||||
The print, pdf and mail icons are copyright Plone Foundation. Thanks for
|
||||
letting me use them!
|
||||
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
|
||||
== SUMMARY ==
|
||||
|
||||
The Recently Read module displays the history of recently read content (nodes)
|
||||
a particular user has viewed. Each authenticated user has its own history
|
||||
recorded, so this module may be useful i.e. for displaying recently viewed
|
||||
products on the e-commerce site. The history is displayed as a block and each
|
||||
content type gets its own block.
|
||||
|
||||
If you need more flexibility, this module can be replaced by properly configured
|
||||
Flag, Rules and Views modules. Check out the following links for more details:
|
||||
* http://drupal.org/node/405754
|
||||
* http://jan.tomka.name/blog/list-recently-viewed-nodes-drupal
|
||||
|
||||
For a full description of the module, visit the project page:
|
||||
http://drupal.org/sandbox/pgorecki/1080970
|
||||
|
||||
To submit bug reports and feature suggestions, or to track changes:
|
||||
http://drupal.org/project/issues/1080970
|
||||
|
||||
|
||||
== REQUIREMENTS ==
|
||||
|
||||
None.
|
||||
|
||||
|
||||
== INSTALLATION ==
|
||||
|
||||
* Install as usual, see http://drupal.org/node/70151 for further information.
|
||||
|
||||
|
||||
== CONFIGURATION ==
|
||||
|
||||
* Customize the module settings in Administer >> Site configuration >>
|
||||
Recently read content. On this pace you can:
|
||||
|
||||
- Select which content types will should be tracked by the module
|
||||
|
||||
After enabling content type tracking, go to Administer >> Site building >>
|
||||
Blocks to configure the block settings of each tracked content type.
|
||||
|
||||
- Recently read list length specifies the maximum number of nodes
|
||||
per user per content type that will be stored in a databse. Note that this
|
||||
is different from "Maximum number of links to display in the block" setting
|
||||
available in the Recently read block configutation options.
|
||||
|
||||
== CUSTOMIZATION ==
|
||||
|
||||
Recently read module lacks UI for advanced configuration, but most tasks can
|
||||
be easily implemented by code snippets or in the theme layer.
|
||||
|
||||
* Displaying more than a node title
|
||||
|
||||
By default, Recently Read block displays a list of links to node titles.
|
||||
You can customize the output by overriding theme_recently_read_item() and
|
||||
theme_recently_read_item_list() functions in your theme.
|
||||
|
||||
For example, to display an image field and a link:
|
||||
|
||||
function mytemplate_recently_read_item($item) {
|
||||
$output = '';
|
||||
if ($item['type'] == 'page') {
|
||||
$node = node_load($item['nid']);
|
||||
if (isset($node->field_image[0])) {
|
||||
$output .= theme('imagefield_item', $node->field_image[0]);
|
||||
}
|
||||
}
|
||||
$output .= l($item['title'], 'node/' . $item['nid']);
|
||||
return $output;
|
||||
}
|
||||
|
||||
* Multiple content types in the same block
|
||||
|
||||
To display multiple content types in the same block, create a new block with PHP body
|
||||
and modify the following examlpe to your needs:
|
||||
|
||||
<?php
|
||||
// disable page caching if this block is displayed
|
||||
recently_read_disable_page_cache();
|
||||
// get 3 recently read pages and articles items for current user
|
||||
// (you can skip the last argument to display all items)
|
||||
global $user;
|
||||
user_is_logged_in() ? $user_id = $user->uid : 0;
|
||||
$items = recently_read_get_read_items(array('page', 'article'), $user_id, 3);
|
||||
// get html string with all items
|
||||
return theme('recently_read_item_list', array('items' => $items));
|
||||
?>
|
||||
|
||||
|
||||
-- CONTACT --
|
||||
|
||||
Current maintainer:
|
||||
* Przemyslaw Gorecki (pgorecki) - http://drupal.org/user/642012
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
$Id: README.txt,v 1.8 2009/06/29 15:29:12 davidlesieur Exp $
|
||||
|
||||
README file for the Role Delegation Drupal module.
|
||||
|
||||
|
||||
Description
|
||||
***********
|
||||
|
||||
This module allows site administrators to grant some roles the authority to
|
||||
assign selected roles to users, without them needing the 'administer
|
||||
permissions' permission.
|
||||
|
||||
For each role, Role Delegation provides a new 'assign <ROLE> role' permission to
|
||||
allow the assignment of that role.
|
||||
|
||||
The module also adds an 'assign all roles' permission. Enabling this permission
|
||||
for a role is a convenient way to allow the assignment of any other role without
|
||||
having to check all the 'assign <ROLE> role' permissions in the Permissions
|
||||
page.
|
||||
|
||||
If an administrator has the 'administer users' permission, a role assignment
|
||||
widget gets displayed in the account creation or editing form. Otherwise, if he
|
||||
has at least the 'access user profiles' permission, the module adds its own
|
||||
'Roles' tab to the user profile so that roles can be assigned.
|
||||
|
||||
|
||||
Installation
|
||||
************
|
||||
|
||||
1. Extract the 'role_delegation' module directory, including all its
|
||||
subdirectories, into your Drupal modules directory.
|
||||
|
||||
2. Go to the Administer > Site building > Modules page, and enable the module.
|
||||
|
||||
3. Go to the Administer > User management > Permissions and scroll down to
|
||||
the role_delegation group of permissions. Each role now has a corresponding
|
||||
'assign <ROLE> role' permission. Grant this permission to roles that shall have
|
||||
the power to assign role ROLE to users.
|
||||
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
********************************************************************
|
||||
D R U P A L M O D U L E
|
||||
********************************************************************
|
||||
Name: Search Restrict
|
||||
Author: Robert Castelo <www.codepositive.com>
|
||||
Drupal: 6.x
|
||||
********************************************************************
|
||||
DESCRIPTION:
|
||||
|
||||
Restrict by role who can search for each content type.
|
||||
|
||||
Approach of this module is to re-write the search query, so that
|
||||
content is indexed and available as search results to users in role(s)
|
||||
that have permissions to view it, but not displayed to other roles.
|
||||
|
||||
********************************************************************
|
||||
PREREQUISITES:
|
||||
|
||||
Search module (Drupal core).
|
||||
|
||||
|
||||
|
||||
********************************************************************
|
||||
INSTALLATION:
|
||||
|
||||
Note: It is assumed that you have Drupal up and running. Be sure to
|
||||
check the Drupal web site if you need assistance. If you run into
|
||||
problems, you should always read the INSTALL.txt that comes with the
|
||||
Drupal package and read the online documentation.
|
||||
|
||||
1. Place the entire module directory into your Drupal modules directory.
|
||||
|
||||
|
||||
2. Enable the module modules by navigating to:
|
||||
|
||||
administer > build > modules
|
||||
|
||||
Click the 'Save configuration' button at the bottom to commit your
|
||||
changes.
|
||||
|
||||
|
||||
|
||||
********************************************************************
|
||||
USAGE:
|
||||
|
||||
On the configuration form of each each content type set the role(s)
|
||||
that can search for nodes of that content type.
|
||||
|
||||
|
||||
********************************************************************
|
||||
TO DO
|
||||
|
||||
Write tests
|
||||
|
||||
|
||||
********************************************************************
|
||||
ACKNOWLEDGEMENT
|
||||
|
||||
Developed by Robert Castelo for Code Positive <http://www.codepositive.com>
|
||||
Initial development sponsored by Greenpeace UK <http://www.greenpeace.org.uk>
|
||||
|
||||
Drupal 6 update by:
|
||||
Hans Nilsson (Blackdog) <http://drupal.org/user/110169>
|
||||
Daniel F. Kudwien (Sun) <http://drupal.org/user/54136>
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
********************************************************************
|
||||
D R U P A L M O D U L E
|
||||
********************************************************************
|
||||
Name: Search Restrict Apache Solr
|
||||
Author: Robert Castelo <www.codepositive.com>
|
||||
Drupal: 6.x
|
||||
********************************************************************
|
||||
DESCRIPTION:
|
||||
|
||||
Restrict by role who can search for each content type when Apache Solr is being used.
|
||||
|
||||
|
||||
|
||||
********************************************************************
|
||||
PREREQUISITES:
|
||||
|
||||
Apache Solr Integration module (Drupal core).
|
||||
|
||||
|
||||
|
||||
********************************************************************
|
||||
INSTALLATION:
|
||||
|
||||
Note: It is assumed that you have Drupal up and running. Be sure to
|
||||
check the Drupal web site if you need assistance. If you run into
|
||||
problems, you should always read the INSTALL.txt that comes with the
|
||||
Drupal package and read the online documentation.
|
||||
|
||||
1. Place the entire module directory into your Drupal modules directory.
|
||||
|
||||
|
||||
2. Enable the module modules by navigating to:
|
||||
|
||||
administer > build > modules
|
||||
|
||||
Click the 'Save configuration' button at the bottom to commit your
|
||||
changes.
|
||||
|
||||
|
||||
|
||||
********************************************************************
|
||||
USAGE:
|
||||
|
||||
On the configuration form of each each content type set the role(s)
|
||||
that can search for nodes of that content type.
|
||||
|
||||
|
||||
********************************************************************
|
||||
TO DO
|
||||
|
||||
Write tests
|
||||
|
||||
|
||||
********************************************************************
|
||||
ACKNOWLEDGEMENT
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
|
||||
Configuration
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
Generally on test/development servers you do not have access to SSL, so
|
||||
generally you would like to disable secure pages on these systems.
|
||||
|
||||
To do this add the following to your settings.php
|
||||
|
||||
$conf['securepages_enable'] = 0;
|
||||
|
||||
Removal of SecurePages
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
In the case where your SSL mode has been disabled and you can no longer access
|
||||
the administration section of your site to disable securepages you can do one
|
||||
of the 2 following things.
|
||||
|
||||
1. Use the above method to disable securepages.
|
||||
2. delete the secure pages module from your site.
|
||||
|
||||
If you can use the first option but if you can't edit your settings.php then
|
||||
deleting it will not break your site, but will leave some variables that are
|
||||
set by secure pages.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
Copy securepages_prevent_hijack/ to your module directory and then enable on the admin modules page.
|
||||
|
||||
In order to prevent getting logged out the first time you enable it, make sure you are accessing admin/build/modules via SSL. If you do get logged out at this point, don't panic, you can just log in again. This should only happen once.
|
||||
|
||||
Also, other users' session will become invalid the first time you enable it. On a busy site with a lot of logged in users, you should consider emptying the sessions table with the following SQL:
|
||||
"truncate sessions".
|
||||
|
||||
It's *not* necessary to change your PHP cookie settings. [1]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This module is intended to prevent hijacked sessions ( http://en.wikipedia.org/wiki/Session_hijacking ) from accessing SSL pages when used with securepages.
|
||||
|
||||
Strictly speaking, this does not *prevent* hijacking, since the session cookie itself. Instead, hijacked sessions are detected, and blocked from accessing SSL pages.
|
||||
|
||||
|
||||
INNER WORKINGS
|
||||
--------------
|
||||
|
||||
Even if a username/password are transmitted to a site over SSL, the session is still subject to hijacking because the session cookie is passed in plaintext. One obvious solution is to require SSL for all requests but this has downsides. A valuable compromise is to prevent a hijacked session ID from being used to access an SSL-protected page; any pages that allow some kind of critical activity (buying products against a stored credit card number or whatever) can then require SSL and know the session ID was not hijacked.
|
||||
|
||||
This is accomplished by using a second session ID cookie with the 'secure' flag set so it is only transmitted to SSL-protected pages. Here's how it would work:
|
||||
|
||||
- When a user logs in, a token is generated via drupal_get_token(). In reply to the login submission (which was to an SSL-protected page), the secure token is sent to the user as a second cookie named SSL_SESSION_NAME with the 'secure' flag set.
|
||||
|
||||
- Whenever a request arrives via SSL, the session is loaded in the normal way (using the non-secure session ID) and then the token is tested with drupal_valid_token(). If it's not valid, the session has been hijacked and the request is refused.
|
||||
|
||||
|
||||
CREDITS
|
||||
-------
|
||||
|
||||
Original concept and securepages patch by bjaspan.
|
||||
|
||||
|
||||
[1] In fact, setting session.cookie_secure would defeat the purpose of this module, and will give you a warning on your site's status page.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
|
||||
Full documentation for SuiteDesk can be found within the folder '/documentation'.
|
||||
|
||||
The exceptions being:
|
||||
- INSTALL.txt in the root folder: Instructions on installing SuiteDesk.
|
||||
- CHANGELOG.txt in the root folder: A list of changes committed.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
|
||||
Documentation for STORM project management application.
|
||||
- Project homepage: http://drupal.org/project/storm
|
||||
- Issue tracking: http://drupal.org/project/issues/storm
|
||||
|
||||
--
|
||||
|
||||
Storm consists of a set of modules as follows: Storm (base module), Attributes (settings), Organizations, Projects, Tasks, Tickets, Timetrackings, People, Notes, Knowledgebase, Invoices and Expenses.
|
||||
|
||||
Each of these provides permissions to control the sharing of data with other users and organizations.
|
||||
NB: This may conflict with other node access modules.
|
||||
|
||||
All components (except Attributes) are nodes, so can be extended as follows:
|
||||
|
||||
* CCK can be used to add more fields to the Storm content types
|
||||
* Views can build customised views
|
||||
* Taxonomy can be used to tag the contents of the Storm nodes
|
||||
* Upload can be used to attach files to Storm nodes
|
||||
* Comments can be used to permit comments on each of the Storm nodes
|
||||
|
||||
Storm content nodes also all link together - for example, an invoice can be associated with an organization and project.
|
||||
|
||||
SEE BELOW FOR DETAILS OF EACH OF THE MODULES INCLUDED WITHIN THE STORM PACKAGE.
|
||||
|
||||
|
||||
--Storm (base module)--
|
||||
This module is required for all Storm installations provides a Storm dashboard which gives quick links for the other Storm modules as well as to the Storm administration section.
|
||||
|
||||
--Storm Knowledgebase--
|
||||
Relying only on the Storm base module, this module provides a content type that can be used to collect together important pieces of knowledge, tips and tricks, and can also categorise them by topic.
|
||||
|
||||
--Storm Attribute--
|
||||
Attributes are the values that are used within Storm, such as task status, countries, currencies etc. This module only relies on the Storm base module, but is needed by all of the following modules.
|
||||
|
||||
--Storm Organization--
|
||||
This module allows you to create nodes relating to the organizations that are the stakeholders of your projects. If you wish to create invoices using Storm, your own organization should be created as an organization here.
|
||||
|
||||
--Storm People--
|
||||
Storm People allows the creation of individual contacts within Organizations, and linking of these to Drupal user accounts.
|
||||
|
||||
--Storm Teammember--
|
||||
This module allows the building of team working on a specific project / task / ticket.
|
||||
|
||||
--Storm Project--
|
||||
Storm project allows creation of projects attached to organizations.
|
||||
|
||||
--Storm Task--
|
||||
Storm tasks are the parts that compose a project and can be hierarchically nested to build a work breakdown structure.
|
||||
|
||||
--Storm Ticket--
|
||||
Storm tickets can be used to track bugs, feature requests, or any other category as specified via attributes. They can be associated with an organization, project or task.
|
||||
|
||||
--Storm Timetracking--
|
||||
This module allows the recording of time spent relating to particular organizations, projects, tasks or tickets.
|
||||
|
||||
--Storm Note--
|
||||
This module allows notes to be attached to organizations, projects or tasks.
|
||||
|
||||
--Storm Invoice--
|
||||
Within Storm Invoice, you can create invoices between yourself and clients. A printer friendly version comes included, and with the addition of the tcpdf library (see the INSTALL.txt), you can also download pdf versions of your invoices directly from Storm.
|
||||
|
||||
--Storm Expense--
|
||||
Storm Expense allows the recording of expenses attached to a specific task or project, including information such as whether it is billable.
|
||||
- Provider: This field will autocomplete with the name of any active organization who is listed as a provider using Storm Organization.
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
/* $Id*/
|
||||
|
||||
-- SUMMARY --
|
||||
|
||||
Storm (http://drupal.org/project/storm) is a nice and handy project management
|
||||
suite for Drupal and it comes with organizations, projects, people, invoices,
|
||||
tasks, notes, and timetracking. This module extends the timetracking functionality
|
||||
by providing a simple block which displays a list on "in progress" projects. The
|
||||
user just selects one of those projects when he/she starts working on that project
|
||||
and as soon as he/she selects a different project, this module creates a records
|
||||
for timetracking and allows quick access to that record to fill in further details.
|
||||
|
||||
In combination with the genius module Storm Dashboard (http://drupal.org/project/storm_dashboard)
|
||||
the timetracking gets even simpler as it becomes available for all relevant node types
|
||||
for Storm, i.e. organizations, projects, tasks and tickets.
|
||||
|
||||
-- REQUIREMENTS --
|
||||
|
||||
* Drupal 6 and Storm.
|
||||
|
||||
-- INSTALLATION --
|
||||
|
||||
* Install as usual, see http://drupal.org/node/70151 for further information.
|
||||
|
||||
-- CONFIGURATION --
|
||||
|
||||
* Configure Storm_QuickTT in Administer >> Storm >> Storm Quick TT
|
||||
|
||||
* Make the Storm-QuickTT block visible in a region of your site in Structure >> blocks
|
||||
|
||||
-- CUSTOMIZATION --
|
||||
|
||||
None
|
||||
|
||||
-- TROUBLESHOOTING --
|
||||
|
||||
Not known yet
|
||||
|
||||
-- FAQ --
|
||||
|
||||
Yet to come
|
||||
|
||||
-- CONTACT --
|
||||
|
||||
Current maintainer:
|
||||
* Jürgen Haas (jurgenhaas) - http://drupal.org/user/168924
|
||||
|
||||
This project has been sponsored by:
|
||||
* PARAGON Executive Services GmbH
|
||||
Providing IT services as individual as the requirements. Find out more
|
||||
from http://www.paragon-es.de
|
||||
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
|
||||
Description
|
||||
===========
|
||||
Token module provides a centralized API for text substitution. Unless
|
||||
you're installing another Drupal module that requires it, this software
|
||||
is probably unnecessary.
|
||||
|
||||
For more information on tokens see http://groups.drupal.org/tokens
|
||||
|
||||
Benefits
|
||||
========
|
||||
If you're a Drupal developer, check out API.txt for detailed instructions
|
||||
on using the Token API. It allows every module to announce the placeholder
|
||||
tokens they can handle, uses simple caching to prevent duplicated work in
|
||||
a given page-view, and is pretty lightweight. It's nice. You'll like it.
|
||||
|
||||
tokenSTARTER
|
||||
============
|
||||
Want to add your own custom tokens to a site? Not sure how to write a
|
||||
module? Worry no more, it's now quite easy.
|
||||
|
||||
1. Copy and rename the tokenSTARTER.info and tokenSTARTER.module replacing
|
||||
every instance of STARTER with a descriptive, appropriate word.
|
||||
|
||||
2. Edit the .module file and change hook_token_list and hook_token_values
|
||||
to provide whatever additional tokens or logic your site needs.
|
||||
|
||||
3. Enable the module and enjoy!
|
||||
|
||||
You should also want to read the API.txt.
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
|
||||
-- SUMMARY --
|
||||
|
||||
Provides a central transliteration service to other Drupal modules, and
|
||||
sanitizes file names while uploading.
|
||||
|
||||
For a full description visit the project page:
|
||||
http://drupal.org/project/transliteration
|
||||
Bug reports, feature suggestions and latest developments:
|
||||
http://drupal.org/project/issues/transliteration
|
||||
|
||||
|
||||
-- INSTALLATION --
|
||||
|
||||
1. Install as usual, see http://drupal.org/node/70151 for further information.
|
||||
|
||||
2. If you are installing to an existing Drupal site, you might want to fix
|
||||
existing file names after installation, which will update all file names
|
||||
containing non-ASCII characters. However, if you have manually entered links
|
||||
to those files in any contents, these links will break since the original
|
||||
files are renamed. Therefore it is a good idea to test the conversion
|
||||
first on a copy of your web site. You'll find the retroactive conversion at
|
||||
Site configuration >> File system >> Transliteration.
|
||||
|
||||
|
||||
-- CONFIGURATION --
|
||||
|
||||
This module doesn't require special permissions.
|
||||
|
||||
This module can be configured from the File system configuration page
|
||||
(Site configuration >> File system >> Settings).
|
||||
|
||||
- Transliterate file names during upload: If you need more control over the
|
||||
resulting file names you might want to disable this feature here and install
|
||||
the FileField Paths module (http://drupal.org/project/filefield_paths)
|
||||
instead.
|
||||
|
||||
- Lowercase transliterated file names: It is recommended to enable this option
|
||||
to prevent issues with case-insensitive file systems.
|
||||
|
||||
|
||||
-- 3RD PARTY INTEGRATION --
|
||||
|
||||
Third party developers seeking an easy way to transliterate text or file names
|
||||
may use transliteration functions as follows:
|
||||
|
||||
if (function_exists('transliteration_get')) {
|
||||
$transliterated = transliteration_get($text, $unknown, $source_langcode);
|
||||
}
|
||||
|
||||
or, in case of file names:
|
||||
|
||||
if (function_exists('transliteration_clean_filename')) {
|
||||
$transliterated = transliteration_clean_filename($filename, $source_langcode);
|
||||
}
|
||||
|
||||
Note that the optional $source_langcode parameter specifies the language code
|
||||
of the input. If the source language is not known at the time of transliter-
|
||||
ation, it is recommended to set this argument to the site default language:
|
||||
|
||||
$output = transliteration_get($text, '?', language_default('language'));
|
||||
|
||||
Otherwise the current display language will be used, which might produce
|
||||
inconsistent results.
|
||||
|
||||
|
||||
-- LANGUAGE SPECIFIC REPLACEMENTS --
|
||||
|
||||
This module supports language specific variations in addition to the basic
|
||||
transliteration replacements. The following guide explains how to add them:
|
||||
|
||||
1. First find the Unicode character code you want to replace. As an example,
|
||||
we'll be adding a custom transliteration for the cyrillic character 'г'
|
||||
(hexadecimal code 0x0433) using the ASCII character 'q' for Azerbaijani
|
||||
input.
|
||||
|
||||
2. Transliteration stores its mappings in banks with 256 characters each. The
|
||||
first two digits of the character code (04) tell you in which file you'll
|
||||
find the corresponding mapping. In our case it is data/x04.php.
|
||||
|
||||
3. If you open that file in an editor, you'll find the base replacement matrix
|
||||
consisting of 16 lines with 16 characters on each line, and zero or more
|
||||
additional language-specific variants. To add our custom replacement, we need
|
||||
to do two things: first, we need to create a new transliteration variant
|
||||
for Azerbaijani since it doesn't exist yet, and second, we need to map the
|
||||
last two digits of the hexadecimal character code (33) to the desired output
|
||||
string:
|
||||
|
||||
$variant['az'] = array(0x33 => 'q');
|
||||
|
||||
(see http://people.w3.org/rishida/names/languages.html for a list of
|
||||
language codes).
|
||||
|
||||
Any Azerbaijani input will now use the appropriate variant.
|
||||
|
||||
Also take a look at data/x00.php which already contains a bunch of language
|
||||
specific replacements. If you think your overrides are useful for others please
|
||||
file a patch at http://drupal.org/project/issues/transliteration.
|
||||
|
||||
|
||||
-- CREDITS --
|
||||
|
||||
Authors:
|
||||
* Stefan M. Kudwien (smk-ka) - http://drupal.org/user/48898
|
||||
* Daniel F. Kudwien (sun) - http://drupal.org/user/54136
|
||||
|
||||
Maintainers:
|
||||
* Andrei Mateescu (amateescu) - http://drupal.org/user/729614
|
||||
|
||||
UTF-8 normalization is based on UtfNormal.php from MediaWiki
|
||||
(http://www.mediawiki.org) and transliteration uses data from Sean M. Burke's
|
||||
Text::Unidecode CPAN module
|
||||
(http://search.cpan.org/~sburke/Text-Unidecode-0.04/lib/Text/Unidecode.pm).
|
||||
|
||||
|
||||
-- USEFUL RESOURCES --
|
||||
|
||||
Unicode Code Converter:
|
||||
http://people.w3.org/rishida/tools/conversion/
|
||||
|
||||
UTF-8 encoding table and Unicode characters:
|
||||
http://www.utf8-chartable.de/unicode-utf8-table.pl
|
||||
|
||||
Country codes:
|
||||
http://www.loc.gov/standards/iso639-2/php/code_list.php
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
$Id: README.txt,v 1.1 2009/09/27 22:07:01 wimleers Exp $
|
||||
|
||||
Description
|
||||
-----------
|
||||
This module provides per-content type 'view revisions' permissions:
|
||||
"view revisions of <content type> content".
|
||||
|
||||
Developed for http://driverpacks.net/
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
1) Place this module directory in your "modules" folder.
|
||||
|
||||
2) Enable the module.
|
||||
|
||||
3) Visit "admin/user/permissions" to configure the newly added permissions.
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
Wim Leers
|
||||
|
||||
* website: http://wimleers.com/
|
||||
* contact: http://wimleers.com/contact
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
|
||||
OVERVIEW
|
||||
|
||||
Nodes hold content. Views save queries. Wouldn't be great if a node could hold a
|
||||
saved query? Now it can. Viewfield is a CCK field module that allows
|
||||
administrators to put views directly into nodes. When creating a node, users can
|
||||
select from a list of views. When the node is displayed, the view is run and the
|
||||
content is inserted into the body of the node.
|
||||
|
||||
|
||||
|
||||
INSTALLATION
|
||||
|
||||
This module requires the views.module and content.module. Enable these modules,
|
||||
then enable viewfield.module. You're ready to go.
|
||||
|
||||
TODO
|
||||
|
||||
1. Provide better control over each view in multiselect fields.
|
||||
2. Use exposed views to allow for more point and click control over the view at
|
||||
node add time.
|
||||
3. Integrate this module back into views when CCK becomes part of core.
|
||||
|
||||
AUTHOR
|
||||
|
||||
Mark Fredrickson
|
||||
mark.m.fredrickson@advantagelabs.com
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
|
||||
Welcome to Views 2. Please see the advanced help for more information.
|
||||
|
||||
If you're having trouble installing this module, please ensure that your
|
||||
tar program is not flattening the directory tree, truncating filenames
|
||||
or losing files.
|
||||
|
||||
Installing Views:
|
||||
|
||||
Place the entirety of this directory in modules/views
|
||||
|
||||
Navigate to administer >> build >> modules. Enable Views and Views UI.
|
||||
|
||||
If upgrading from Drupal 5 and Views 1, your views need to be
|
||||
converted manually. See administer >> build >> modules >> views >> tools >> convert.
|
||||
|
||||
If you're new to Views, try the Simple Views module which can create some
|
||||
often used Views for you, this might save you some time.
|
||||
|
||||
Recommended modules for use with Views:
|
||||
CCK
|
||||
Voting API
|
||||
Views Bonus Pack
|
||||
Views Bulk Operations
|
||||
|
||||
Experimental modules:
|
||||
Views OR
|
||||
|
|
@ -1,252 +0,0 @@
|
|||
Watcher Module for Drupal 6.x
|
||||
|
||||
Feature overview
|
||||
|
||||
* Lets users watch nodes for changes or new comments being posted without
|
||||
having to post themselves.+
|
||||
* Uses AJAX to toggle watching for a smooth user experience.
|
||||
* Allows both anonymous and registered users to watch nodes.
|
||||
* Supports email notifications being sent when both or either of the
|
||||
above occurs.
|
||||
* Template-based notification messages using the Token module - edit the
|
||||
templates to your liking!
|
||||
* Provides a binder with an overview of the nodes you watch. From the
|
||||
binder you can also toggle email notifications for each node you watch.
|
||||
* Users may choose to publish the binder so that other users can see what
|
||||
they're watching, providing a form of social bookmarking.
|
||||
* Uses a queue-based email dispatcher to handle large numbers of notifications.
|
||||
* Users can opt to automatically watch nodes they create or comment on.
|
||||
* User settings can have default values, set by the site owner, that can be
|
||||
customized and overridden by the user.
|
||||
* Highly customizable, configurable user interface and themeable.
|
||||
* Designed with usability and exceptional user experience as a high priority.
|
||||
|
||||
Watcher was developed to fill a gap that has existed for a long time. Even
|
||||
though there are several subscription and notification modules out there,
|
||||
none is both easy to use or particularly specialized and allows instant
|
||||
(or near instant) notifications. Watcher is not a general solution to
|
||||
notifications but caters to the needs of community sites.
|
||||
|
||||
+Added in the Drupal 6 version.
|
||||
|
||||
|
||||
Requirements
|
||||
------------
|
||||
To install this version of Watcher you need:
|
||||
|
||||
* Drupal 6.x
|
||||
* Comments module (included in Drupal)
|
||||
* Node module (included in Drupal)
|
||||
* Token module (http://drupal.org/project/token)
|
||||
|
||||
There's a version for Drupal 5 as well, available from:
|
||||
http://drupal.org/project/watcher
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
To install Watcher, do the following:
|
||||
|
||||
1. Download, install and configure the Token module, follow the
|
||||
instructions for that module.
|
||||
|
||||
2. Download the latest stable version of Watcher from its project
|
||||
page: http://drupal.org/project/watcher
|
||||
|
||||
3. Unpack the file you downloaded into the modules directory of your site.
|
||||
|
||||
4. Go to Administer » Site building » Modules and enable the module.
|
||||
|
||||
5. Go to Administer » Site configuration » Watcher and select at least
|
||||
one content type for the module.
|
||||
|
||||
NOTE: The module will not work and users will not be able to watch
|
||||
posts unless you select at least *one* content type.
|
||||
Click "Save configuration" to save your changes.
|
||||
|
||||
|
||||
Upgrading from Drupal 5
|
||||
-----------------------
|
||||
If you've been using a previous version of Watcher, make sure you go to update.php
|
||||
and run the update script after uploading the new module files.
|
||||
|
||||
|
||||
Issues
|
||||
------
|
||||
In case Watcher does not appear to work for anonymous users even though the
|
||||
role Anonymous has been granted the necessary permissions, your users table
|
||||
may be missing the anonymous user.
|
||||
|
||||
To fix this, first empty your site's cache. You can do that by going to
|
||||
Administration » Site Settings » Performance
|
||||
|
||||
Secondly, make sure there's a row with uid 0 in your site's users table.
|
||||
You can confirm that by executing this SQL query:
|
||||
SELECT * FROM `users` WHERE uid = 0;
|
||||
|
||||
The query should return exactly one row. If no row is returned, the row is
|
||||
missing and must be restored. Execute this query to add the row:
|
||||
INSERT INTO `users` VALUES (0, '', '', '', 0, 0, 0, '', '', 0, 0, 0, 0, NULL, '', '', '', NULL);
|
||||
|
||||
See: http://drupal.org/node/370459
|
||||
|
||||
|
||||
CAPTCHA support and preventing spam
|
||||
-----------------------------------
|
||||
Since Watcher now supports anonymous users watching nodes, CAPTCHA support has
|
||||
been added to help prevent spam submissions. Download CAPTCHA module:
|
||||
http://www.drupal.org/project/captcha
|
||||
|
||||
Watcher is known to work with CAPTCHA 6.x-1.0-rc2 and probably also all subsequent
|
||||
6.x-1.0 release. Compatibility with 6.x-2.0 and later is not confirmed at this point.
|
||||
|
||||
Install CAPTCHA and set up its permissions as needed. Then go to:
|
||||
admin/user/captcha/captcha/captcha_point
|
||||
|
||||
Enter "_watcher_watch_toggle_anonymous_form" (quotation marks omitted) in the
|
||||
"Form ID" field. Select a challenge type and save the form. CAPTCHA will now display
|
||||
the challenge you selected when anonymous users want to start watching a node.
|
||||
|
||||
To implement a first line of defense against spambots you can use the Bad Behavior
|
||||
module. It uses heuristics to determine whether the browser is a genuine
|
||||
human-controlled software application or an automated spambot:
|
||||
http://drupal.org/project/badbehavior
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
The module can be configured by going to:
|
||||
Administer » Site configuration » Watcher
|
||||
|
||||
You can customize a wide range of options. Most of this is quite straight-forward
|
||||
however some things may require an explanation.
|
||||
|
||||
Under "Settings for Email Notifications" you can choose what method to use for
|
||||
sending emails. This will have an impact on how many messages are sent at once.
|
||||
Watcher stores notifications to be sent in a message queue and every time messages
|
||||
are sent they're taken off the queue. The method affects when the queue messages are
|
||||
actually sent, it can either happen when cron and cron.php is being run or when a
|
||||
user posts a comment.
|
||||
|
||||
If there are many messages in the queue, the best setting to use is cron and making
|
||||
sure cron is run frequently enough that the entire queue is being processed. You can
|
||||
change the time limit for message sending. The server will send as many messages as
|
||||
possible during this interval. Any messages left unsent will remain in the queue
|
||||
until it is processed again.
|
||||
|
||||
You may also modify the notification message templates that are used to generate the
|
||||
notification messages. You can use placeholder tokens to insert the content that
|
||||
changes, such as recipient name and comment excerpt.
|
||||
|
||||
Watcher also allows every user on your site to customize how the module works for them.
|
||||
Users may enable or disable email notifications and make it so that they automatically
|
||||
watch every post they make or comment on. Users who have not yet altered these settings
|
||||
will be affected by the user settings defaults. These default settings apply until a
|
||||
user goes to his or her settings page for Watcher and clicks "Save".
|
||||
|
||||
The page titled Statistics shows some basic statistics about the module which may be of
|
||||
interest to you as a site owner. If there are unsent messages in the message queue,
|
||||
these can be viewed here as well.
|
||||
|
||||
The Testing page allows you to do testing in case notification messages are not being
|
||||
delivered. You can create test messages that are sent to your own email address.
|
||||
|
||||
|
||||
Retroactively add existing posts
|
||||
--------------------------------
|
||||
If you have a large site and a large quantity of nodes/posts you may want to add the
|
||||
existing nodes your users have made or commented on to their watched posts lists.
|
||||
|
||||
You can do this by running the SQL queries below. The queries below will do the
|
||||
following:
|
||||
- add all posts a user has created to his/her watched posts list
|
||||
- add the nodes belonging to every comment a user has made to his/her watched posts list
|
||||
|
||||
CAUTION: Make a database dump to keep as a backup copy before attempting this!
|
||||
CAUTION: The following has only been tested with MySQL 5!
|
||||
|
||||
INSERT IGNORE INTO watcher_nodes (uid, nid, send_email, added) SELECT uid, nid, 1, UNIX_TIMESTAMP() FROM node;
|
||||
INSERT IGNORE INTO watcher_nodes (uid, nid, send_email, added) SELECT uid, nid, 1, UNIX_TIMESTAMP() FROM comments;
|
||||
|
||||
|
||||
Theming
|
||||
-------
|
||||
Watcher is entirely themable. Open watcher.module in your editor to see what
|
||||
theme functions are available to be overridden. The functions are documented in
|
||||
detail in the code.
|
||||
|
||||
Themable functions of interest:
|
||||
* watcher_binder($intro_text, $posts_table_header, $posts_table_body)
|
||||
* watcher_binder_email_icon($t, $type, $url, $dest)
|
||||
* watcher_binder_stop_watching_icon($url, $dest)
|
||||
* watcher_node_toggle_watching_link($uid, $nid, $dest, $user_is_watching)
|
||||
* watcher_help_page($content)
|
||||
|
||||
Watcher outputs the watcher link at the end of the node's body by default. A future
|
||||
feature will be to make this configurable, allowing the link to be output in the
|
||||
node's links section, at the beginning or end of body or in a separate template
|
||||
variable. Until then, you can use the following method to separate the watcher link
|
||||
from the node's body.
|
||||
|
||||
In node.tpl.php, to display the watcher link:
|
||||
|
||||
<?php if($node->content['watcher']['#value']): ?>
|
||||
<div class="node_watcher">
|
||||
<?php print $node->content['watcher']['#value']; ?>
|
||||
</div>
|
||||
<?php endif; ?>
|
||||
|
||||
And the node's body:
|
||||
|
||||
<div class="content">
|
||||
<div class="content_description"><?php print $node->content['body']['#value']; ?></div>
|
||||
</div>
|
||||
|
||||
For more info, please see: http://drupal.org/node/11816
|
||||
|
||||
|
||||
Terminology
|
||||
-----------
|
||||
I have tried to consistently use the term "post" in the parts of the module that
|
||||
the end users see as it makes way more sense to non-Drupallers than the word "node".
|
||||
In the code comments and documentation, I've used the word "node" where I talk
|
||||
about nodes.
|
||||
|
||||
The word "binder", is used interchangeable with the term "watched posts list". They're
|
||||
exactly the same thing, "binder" is a term Hans Dekker of Wordsy.com suggested and it's
|
||||
stayed in the module since its first versions.
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
The module was developed by Jakob Persson <http://drupal.org/user/37564> of
|
||||
NodeOne, Sweden's leading Drupal consulting firm. Our goal is to empower the
|
||||
user by building usable, powerful and effective web solutions for our clients.
|
||||
Visit us at http://www.nodeone.se
|
||||
|
||||
I am a developer that considers usability and user experience to be some of the
|
||||
defining properties of successful software applications as well as devices and
|
||||
appliances. I have a background in cognitive science and HCI and I work with
|
||||
user experience and usability at NodeOne, building beautiful, usable
|
||||
web sites and intranet applications for our clients.
|
||||
|
||||
The author can be contacted for paid customizations of this module as well as
|
||||
Drupal consulting, installation, development and customizations.
|
||||
|
||||
|
||||
Sponsors
|
||||
--------
|
||||
The development of this module has been sponsored by
|
||||
|
||||
* Wordsy <http://www.wordsy.com>
|
||||
* NodeOne <http://www.nodeone.se>
|
||||
|
||||
|
||||
Thanks
|
||||
------
|
||||
To Hans Dekker <http://www.hansdekker.com> for the idea as well as suggestions
|
||||
and feedback.
|
||||
|
||||
Some of the icons were either taken directly from the Tango Icon Library or were
|
||||
derived from Tango icons.
|
||||
http://tango.freedesktop.org/
|
||||
Reference in a new issue