WebGUI is a mature, feature rich Content Management System. It's written in Perl and licensed under the GNU GPL. Some features include:
Deploying a Docker Image is the easiest method.
The Source Install process should support any system that supports MariaDB or MySQL, has a semi-recent version of Perl, and is supported by the necessary system libraries (libgd, for example).
An experimental Docker image is available on Docker Hub:
XXX where are they? Probably don't want to publish these under my name. Create an org?
t.b.d.
See https://docs.docker.com/install/ for instructions on installing Docker.
Once Docker is installed, run these commands as root to start WebGUI:
docker pull scrottie/webgui8 # XXX old image; new one may be at a different location
docker run -p 80:80 scrottie/webgui8:latest # adding '-t -i' flags runs it interactively
If not run interactively, docker ps -l
shows the last Docker container started, docker log <id>
shows the output (which will be the plack
process output for WebGUI), and docker stop <id>
stops it.
Use docker stop <id>
to stop the container and docker start <id>
to start it again. docker ps -a
shows all containers, including stopped ones.
Each time docker run
is executed, a new, distinct, persistent copy of WebGUI's database and uploads will be created. Generally, you'll want to only one or a few containers, and then continue to re-start that same one or few. That way, changes you've made in the CMS are persisted.
See http://docker.com for more usage information, and for installation instructions for Windows and Mac OSX.
Please report problems and suggestions for improvements for that in the Docker ticket at https://github.com/AlliumCepa/webgui/issues/8 or on https://github.com/AllumCepa/webgui/issues.
Use this manual installation from source for OSX, FreeBSD, and other systems, or for those who like to see exactly what is happening.
You'll need the system packages (dev or source installs of needed libraries) used by wG and the Perl modules wG uses. On Debian, at least the following system packages are needed:
apt-get install
perl cpanminus libaspell-dev make libdbd-mysql-perl libdigest-perl-md5-perl libxml-simple-perl \
libmodule-install-perl gcc libperl-dev libmysql++-dev libpng-dev build-essential libgd-dev mariadb-client
This assumes that your site is "www.example.com". If it's something else, change the commands to match.
Generic source install instructions:
perl sbin/testEnvironment.pl
to install Perl module depswww_whatever_com
share/create.sql
into your MySQL/MariaDB/Perconaetc/www.whatever.com.conf
dbuser
, dbpass
, dsn
, uploadsPath
(eg to /data/domains/www.example.com/public/uploads/
), extrasPath
, maintenancePage
, and siteName
. You can point extrasPath
at the existing copy under www/extras
if you're only hosting one site on wG. Otherwise, make a per-site copy.extras
directory from whereever you unpacked it to whereever you pointed extrasPath
to in the config file.etc/log.conf
etc/log.conf
such that log4perl.appender.mainlog.filename
points to a writable path. For example: log4perl.appender.mainlog.filename = webgui.log
works for local developmentWEBGUI_CONFIG
to point at your new config file. For example: export WEBGUI_CONFIG=www.whatever.com.conf
wgd reset --upgrade
More detailed (but less well maintained) instructions are in docs/install.txt.
To test or develop:
See docs/install.txt for more detailed installation instructions.
A production site or a dev site that tests sending email or workflows will also need the spectre daemon running.
A proxy server such as nginx or Apache configured to proxy is highly recommended for production sites. The proxy server should serve /extras and /uploads and pass everything else to the plack server process. See docs/install.txt for a recommended plack configuration for production.
We welcome contributions.
Where things are at:
If you connect to IRC, please be patient. If you're not able to wait for a response, please consider email instead.
As a general rule, if you're fixing a bug mentioned in http://www.webgui.org/8, discuss it at http://www.webgui.org/webgui/dev/discuss. If you're adding a new feature or want to talk about the community process itself, discuss it on https://github.com/AlliumCepa/webgui/issues/.
If you're adding a new feature, improving wG, or fixing bugs, please fork http://github.org/AlliumCepa/webgui.
There are plenty of ways to help:
Fork http://github.org/AlliumCepa/webgui, make changes in master or in a branch, commit them, push them up, and then use github to send a "pull request". If the request is accepted, your code goes into http://github.org/AlliumCepa/webgui.
Here are some specific tasks to be done:
Rules and process:
This needs to be moved to a design document.
$wg
WebGUI object (one per site).$wg
creates and stores the WebGUI::Config
(one per site)$wg
creates the $app
PSGI app code ref (one per site)WebGUI::Middleware::Session
is wrapped around $app
at the outer-most layer so that it can open and close the $session
WebGUI::Session
. Any other wG middleware that needs $session
should go in between it and $app
($session
created one per request)$session
creates the $session->user WebGUI::User
, $session->request
WebGUI::Session::Request
, and $session->response
WebGUI::Session::Response
objects (one per request)lib/WebGUI.pm
does basic dispatch, first checking for a content handler, and then as a last resort (but the usual case), defaulting to the asset content handler. Content handlers are listed in the config file, in order.