Jump to content

Is it wise to use ProcessWire for a multi-user Intranet knowledge base?


johnstephens
 Share

Recommended Posts

Hi,

I'm hammering out the details of a project for a consortium of counseling organizations. They need a new site for sharing private case information and related knowledge, and they have a very small budget.

My question is: Is this site a good fit for ProcessWire, or should I build this using a Wiki engine like MediaWiki or DokuWiki? Or something else?

Here are some of the requirements:

  • The site is access-protected so that only authorized accounts can see any site content at all—approximately 20 active users at a given time.
  • Content types: The majority of content would be informational articles in formatted text, but the site will give them easy control over a dynamic, hierarchical category list under which content can be easily organized. They will also need to upload and link to documents, including PDFs and Word docs. All content, including uploaded files, would be available only to logged-in user accounts.
  • Multiple editors: Users can update text, create new pages, add categories, and upload and link documents. All users would have editor privileges, but they anticipate fewer than 10 will actually do it.
  • Recent updates: They want a section that lists recent substantial updates to the site. Based on the discussion, they prefer not to include minor article edits (like a phrase being changed to bold, for example), but only edits that change the content in substance—sounds like this could easily be accomplished with an internal blog.
  • Alerts: Any member can post a comment on an article to note current questions or issues about the content. The purpose is to resolve the questions or issues and improve the article content, not to maintain a persistent discussion about article content.
  • Full-text search
  • Quick navigation: A concise list of links to highest-traffic content will be available on every page. This navigation menu should be easy to add, remove, sort, or edit links by the editors.
 

I have two further requirements, for my own sake:

  • Simplicity of user-facing interface: I don't want the publishing software to present the editors with superfluous configuration and options they might use to break the site, or require extensive documentation for.
  • Stablility, security, and ease of maintenance: I don't want to introduce security vulnerabilities or create long-term maintenance difficulties simply by customizing the front-end page designs.
 

It occurs to me that Wiki software has most of the above features built-in. But I have a few misgivings about using a Wiki:

Wikis include a lot of built-in functionality that I imagine would make it incredibly complex to create a skin. I know that ProcessWire would allow me to write my own markup, and keep the page designs as simple as possible.

I'm also afraid that I might introduce security vulnerabilities or maintainability problems if I create my own skin for a Wiki. I know that ProcessWire enables you to include back-end functionality in front-end templates, but you don't have to do that. I'm confident that I would have to do some obvious and deliberately reckless design in order to create any security problems with ProcessWire.

On the other hand, I don't want to spend weeks building out functionality that a Wiki, or other easily-available software, offers with basic installation.

Any guidance, warnings, advice, or further thoughts would be greatly appreciated.

Cheers!

John

  • Like 1
Link to comment
Share on other sites

I have done something like this half a year ago. I made an intranet for a company with 200 employees. There are no problems I heard of so far. It has a full text search, a searchable image repository with thousands of photos, every user has his own profile with his portrait... Most important thing was: every download of this intranet (PDF, Word, Excel, image files and so on...) is a page. I have build a  small multi file importer which allows to upload many files at once, which leads to creation of the according amount of pages with these files attached. I did this to give each file more properties (think of it as an" asset management" - every file can have properties like view rights,  tags, relations, descriptions, authors etc.). To assign this download pages to their parent "content pages" (the page the visitor sees in frontend view) I did use page tables very much. I think it works very good and I enjoyed it to develop and customize.

  • Like 6
Link to comment
Share on other sites

On the other hand, I don't want to spend weeks building out functionality that a Wiki, or other easily-available software, offers with basic installation.

I think this is your limiting factor here. I have built something similar as part of a wider, integrated intranet system however if your time is short you can't beat using some pre-existing software.

Nothing will beat ProcessWire if you are likely to want to introduce functionality not available in some other system as ProcessWire is one of the few platforms where you can change your mind about something or come up with crazy new ideas and it not be a problem to make larger changes, but if you're likely to only need a normal WIKI type system then you probably won't replicate all the functionality you want in just a few weeks.

That said, I hate that MediaWiki seems to be the main option out there (there are others, but they all come with their own maintenance issues too) as it's a bloated piece of software (so slow and resource hungry for what it does) on an out of date codebase in my opinion. I would love to have the time and money to develop something in PW as coupled with ProCache you'd be onto a winner and have something infinitely more customisable if a lot simpler, but it would be a project that would take several months at least I would think to cover everything (well, the basics) of what something like MediaWiki can do.

Not sure where my train of thought is going, but I guess if you're really tight on time, you should probably invest that in installing, skinning and getting to grips with something that already exists. If the project is longer-term overall (as in you'll be looking after this system for years), then this buys you time to develop something as a version 2 and does you a favour in a way as you'll know what the client does and doesn't use in the system you've installed so you know where to focus your efforts in a custom-built system.

Hope that's of some help anyway.

  • Like 3
Link to comment
Share on other sites

In defense of MediaWiki, it seems that they are dragging their codebase kicking & screaming, laughing & giggling into the present.

Their most recent release included API cleanup: "A large amount of time was spent cleaning up the API, making the output saner, and friendlier for new developers to use".

They do have a minimum req. of PHP 5.3.3, so way ahead of WP ;). They want to switch to 5.5 minimum soon.

They now use Composer for external deps.

The latest beta has initial HHVM support and they are putting a lot of effort on performance improvements.

Edit (to add some stuff without spamming this topic too much): they are also looking to improve the development experience in general, not only for MW core devs. So API polishing and documentation will be a long-term commitment.

PHP 5.5 minimum is completely reasonable. OVH Hosting will discontinue PHP 5.3 support in September.

  • Like 1
Link to comment
Share on other sites

Hmm... that's a lot of big changes. I wonder why they didn't opt to call that the 2.x branch and then they could make all the changes they like and let the community continue contributing to the 1.x branch as long as they like?

Seems to be a lot of things to take into consideration when upgrading, and more breaking changes to follow in 1.26.

But I'm happy they're making some changes anyway.

Link to comment
Share on other sites

  • 1 month later...

The above advice was very useful to me, thank you all!

Given the short turn-around time in my project schedule, I installed and configured MediaWiki, and devoted the bulk of my time on documentation and training instead of development. I found a very simple off-the-shelf skin that seems to be well-maintained, and used MediaWiki's "Common.css" page to add my own customizations.

Thank you so much for the help! I'm sure the site could have been a lot leaner had I used ProcessWire, but I'm also pretty sure that I'd still be working on core functionality right now instead of delivering something they can use right away, and they need it.

Thanks again!

  • Like 2
Link to comment
Share on other sites

Not a problem, and glad it worked out for you. Sometimes the easy way is the way to go when you're on a tight timescale that can't be changed, even if you know there could be a better way.

Web developers aren't supermen after all (with the exception of Ryan of course).

What was the skin you used in the end, just out of curiosity? I don't really like the default one that ships with MediaWiki myself - feels a bit outdated.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...