Related
I'm researching MODX as a CMS and found this interview with the creator of FoxyCart.
He really gives MODX a lot of positive comments and when asked about improving MODX he pointed out the following:
User management can be awkward, and
some things related to webusers have
never really been brought current.
(Newspublisher can’t handle TVs;
Weblogin is temperamental and not easy
to customize; Webusers need “TVs” for
additional fields.)
Can others on this site shed some light on this? What other kind of user management issues are there?
What are some areas of MODX that people think should be improved?
I'm trying to figure out whether to go with MODX or not. I've been reading a lot of positive things about it and want to make sure that I get the whole picture.
Brett (Foxycart) is talking about MODX Evolution, the older codebase, and makes reference to add-ons, which are (for the most part) independently authored - so definitely improvable. MODX Revolution is the newer version, currently at 2.1 RC3. I've worked with everything from Enterprise CRMs (Tridion, Rhythmyx, Mediasurface as was) to other FOSS systems Silverstripe, Wordpress etc, and it is by far the most intelligently put together and executed of the lot.
It has some niggles - the permissions system is overly abstract and complex, it lacks some plug-and-play features, fine-tuning performance is a bit of a black art, and it doesn't have the ecosystem support of bigger players like Drupal or Joomla (or even WP). But the peer support is fantastic, the core team are committed and talented, and with a modicum of php and willingness to RTFM you can make it do almost anything with MODX.
Strongly recommended.
Everything can be improved, Wordpress or Drupal included, thats generalizing the topic. MODx is awesome piece of 0's and 1's which will cut your development time so much that your head will spin. Its easy to use and develop with and its fast. As far as im concerned, its web designers dream to work with. I sat give it a local spin and try playing for a day and decide afterwards.
Here are some of tuts i compiled in URL list for easy learning:
http://urli.st/3Tg
Also, Twitter #modx is also great resource to be in sync with the matter.
Hope you'll find it good!
good luck!
I've used several Content Management Platforms, and ultimately the experience has always been similar. While I can put up a site lickety-split, I have often wanted to override functionality or its output and couldn't do so without wading through large amounts of PHP files. This has always resulted in a large unsatisfactory result, because I am not lazy, unless I have to wade through others code.
When I started ModX, one week ago, the learning curve hit me like a brick. Mostly this was because it was so simple and I had been trained to deal with CMSes in complex manners. It is much more like a true Object Oriented platform (to me), and as I am an OO programmer, this fit the bill once I realized it was not as complex as I was making it out to be.
Now, in less than a week I have two nearly complete websites (a corporate software development with a shopping cart and a development blog) in less than 1/4 of the time it took me to make my original Corporate website. I'm at the tweaking style and adding content more quickly and easily than I have ever done with a CMS. I did all of the work as well. Injecting my own PHP, HTML, and CSS was amazingly easy, and I did not have to search and rely on hacky plugins to get the job done.
That being said, there are a number of ways in which ModX could be improved. The Manager uses Ajax, but most of the time it is used way too often on a full page refresh anyway. This does slow things down. The User Management is awkward, at first, and honestly should be revisited as time and community allows. The tutorials are improving, but are weak without the videos to accompany them (in my opinion). And there is a lack of variety of useful plugins, but the plugins they have are extremely useful and can be tailored for nearly any solution.
As a final note: the most useful feature is the abstraction of the properties and property sets. This allows you to override your overall site settings, for things as simple as a template or page.
FuzzicalLogic
Putting up a simple photo gallery can be a nightmare.
There is a plug in component that is very obtuse and cumbersome to implement. This is a glaring weakness when you are comparing to, say, WordPress, who are very much MODx's competition for the hearts and minds of developers.
My 5 minutes experience with Modx (2.1.3-pl)
installed the latest (stable) version then try to run the site.
1) Error 503, site unavailable.
okay, it should show a link to the setup page but a quick search in internet showed how to open the setup manually.
2) PDO is required... well, it is starting to stink. PDO is slow
them i activated PDO in my PHP, restart apache and entered the "Connection Information" form and clicked in "Test database server connection and view collations." and
3) "Test database server connection and view collations." javascript error.. i tried with other browser and it is the same.
nuff said.
I learn best by taking apart something that already does something and figuring out why decisions were made in which manner.
Recently I've started working with Perl's CGI::Application framework, but found i don't really get along well with the documentation (too little information on how to best structure an application with it). There are some examples of small applications on the cgi-app website, but they're mostly structured such that they demonstrate a small feature, but contain mostly of code that one would never actually use in production. Other examples are massively huge and would require way too much time to dig through. And most of them are just stuff that runs on cgiapp, but isn't open source.
As such I am looking for something that has most base functionality like user logins, db access, some processing, etc.; is actually used for something but not so big that it would take hours to even set them up.
Does something like that exist or am i out of luck?
CGI::Application tends to be used for small, rapid-development web applications (much like Dancer, Maypole and other related modules). I haven't seen any real examples of open-source web apps built on top of it, though perhaps I'm not looking hard enough.
You could look at Catalyst. The wiki has a list of Catalyst-powered software and there are a large number of apps there - poke around, see if you like the look of the framework. Of this, this is Perl, so some of those apps will be using Template::Toolkit, some will use HTML::Mason... still, you'll get a general idea.
Try looking at Miril CMS. Although I don't know in which state it is.
I am the same with code, and had the same request. When I did not find a solution I created my own. which is https://github.com/alexxroche/Notice
I hope that it is a good solution to this request.
Notice demonstrates:
CGI::Application
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::AutoRunmode
CGI::Application::Plugin::DBH
CGI::Application::Plugin::Session;
CGI::Application::Plugin::Authentication
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::DBIC::Schema
CGI::Application::Plugin::Forward
CGI::Application::Plugin::TT
It comes with an example mysql schema, but because of DBIC::Schema it can be used with PostgreSQL, (or anything else that DBIx::Class supports.)
I use Notice in all of my real life applications since 2007. The version in github is everything except the branding and the content.
Check out the Krang CMS.
I need to create a internal website and can't figure out if we should be writing our own, or using an existing framework.
Most of the website will essentially be a front end to a database. We need to have a number of people enter data into forms. We then want to be able to show different views of all this data -- including running small queries (e.g. how many resources do we have with attribute 'X'). As is usually the case with this, we will want to tweak the UI on a regular basis.
There actual data design is not a simple 1:1 mapping of resource to entry. For example, we might track several attributes for one item as the "base set of data" for that item. Then we could have several additional sets of data.
Imagine a recipe application. You might have a recipse for a starter. This could then be referenced by several other recipes that need that same information.
I feel like this is best suited for a general framework (Ruby on Rails, Django, etc), but I wonder if it might not be good for a "traditional" CMS platform like Drupal? I specifically mention Drupal since the people that would develop this have the most knowledge using php and MySql.
I usually lean towards wanting to use an existing platform, but am interested in other people's thoughts. To give you an idea of scope, I would imagine if we wrote this from scratch we are probably talking about 3-5 weeks of development.
Would you recommend writing our own, or using an existing framework? If you would suggest using something that exists what would you recommend?
Would you consider this to be best suited for a straight framework or a straight CMS?
Thanks!
It's possible that Drupal will be a good solution for you, though you'll probably need a few key additional modules like the "Content Creation Kit" (CCK) and "Views".
Unlike other web CMS systems (WordPress, Exponent, phpNuke), Drupal treats your entries as a "pool" of content, from which you pull various subsets for different areas of your site.
There is a lot of documentation for Drupal (almost too much), the biggest problem is finding the piece that's relevant to what you're trying to achieve. Diving on to one of the interactive IRC channels can be a good idea, as the community is quite helpful and is almost always willing to give you a pointer in the right direction.
The power, flexiblity and capability of Drupal is both its biggest strength and weakness - I know it took me a bit of effort to get my head around key concepts, and I'm far from being a Drupal Expert.
One last comment: Having written my own CMS from scratch, which I abandoned in favour of Drupal, I'd suggest your 3-5 week estimate is likely on the light side.
Stay away from Drupal for any site that requires customized functionality. I recently used Drupal for a website at work, and it was VERY difficult to figure out how to get it to do what I wanted it to do. There is a lot of documentation out there, but all of it is unhelpful -- it answers very specific questions about specific issues but does not provide any context as to how you would approach building the site as a whole. If you're a programmer, using a more general framework will probably work better, as CMS's are designed for a specific kind of site, and if you want your site to have non-standard functionality you are going to be fighting the system instead of working with it. If your developers are most experienced in PHP, try one of the PHP frameworks that mimics the architecture of Rails -- e.g. cakePHP or CodeIgniter.
CMSes usually make sense when you have a broad and potentially expanding array of different content types and modes you need to handle. Drupal has literally dozens. Given than you mentioned RoR, it sounds like what you need is more of a MVC style framework. Maybe similar to the sort of thing stackoverflow was built with. .NET an issue for you?
If you are really limited to 3-5 weeks, however, I think a Rails-based strategy makes sense so go with RoR or CodeIgniter
If Drupal can do what you need easily I would say go with Drupal. I don't know much about Drupal though.
Otherwise, what you describe sounds like a data driven web app or more like a reporting app. It sounds like you might have some very specific needs or that users might want very specific needs in the future. That is something hard to get from premade software since you have no idea what users are going to request. Since I'm a programmer I would probably want to build it myself.
Funny you should ask... I just came across this in SD Time's Linkpalooza this afternoon:
Ten free powerful content management systems…
There are at least 4 more mentioned in the comments to this post.
It seems to make little sense to develop a new one with so many from which to choose!
BTW, this is neither a recommendation nor endorsement of any particular CMS.
Treat Drupal as a framework. Core modules + CCK + Views is a good start to build on.
If you're doing something that you might want to expose to other applications, consider the Services module. A lot of interesting things have been done with flex frontends connected to drupal running services with amfphp.
Does anyone know of a good code obsfucator for Perl? I'm being ask to look into the option of obsfucating code before releasing it to a client. I know obsfucated code can still be reverse engineered, but that's not our main concern.
Some clients are making small changes to the source code that we give them and it's giving us nightmares when something goes wrong and we have to fix it, or when we release a patch that doesn't work with what they've changed. So the intention is just to make it so that it's difficult for them to make their own changes to the code(they're not supposed to be doing that anyway).
I've been down this road before and it's an absolute nightmare when you have to work on "obfuscated" code because it drives up costs tremendously trying to debug a problem on the client's server when you, the developer, can't read the code. You wind up with "deobfuscators", copying the "real code" to the client's server or any of a number of other issues which just become a real hassle to maintain.
I understand where you're coming from, but it sounds like management has a problem and they're looking to you to implement a chosen solution rather than figuring out what the correct solution is.
In this case, it sounds like it's really a licensing or contractual issue. Let 'em have the code open source, but make it a part of the license that any changes they submit have to come back to you and be approved. When you push out patches, check the md5 sums of all code and if it doesn't match what's expected, they're in license violation and will be charged accordingly (and it should be a far, far higher rate). (I remember one company which let us have the code open source, but made it clear that if we changed anything, we've "bought" the code for $25,000 and they were no longer responsible for any bug fixes or upgrades unless we bought a new license).
Don't. Just don't.
Write it into the contract (or revise the contract if you have to), that you are not responsible for changes they make to the software. If they're f-ing up your code and then expecting you to fix it, you have client problems that aren't going to be solved by obfuscating the code. And if you obfuscate it and they encounter an actual problem, good luck in getting them to accurately report line number, etc., in the bug report.
Please don't do that. If you don't want people to alter your Perl code then put it under an appropriate licence and enforce that licence. If people change your code when you licence says that they shouldn't do that, then it's not your problem when your updates not longer work with their installation.
See perlfaq3's answer to "How Can I hide the source for my Perl programs? for more details.
It would seem your main issue is clients modifying code which then makes it difficult for you to support it. I would suggest you ask for checksums (md5,sha, etc) of their files when they come to you for support, and similarly check files' checksums when patching. For example, you can ask the client to provide the output of a provided program which goes through their install and checksums all the files.
Ultimately they have the code, so they can do whatever they want to it. The best you can do is enforce your licenses and to make sure you only support unmodified code.
In this case obfuscating is the wrong approach.
When you release the code to the client you should keep a copy of the code you send them (either on disk or preferably in your version control as a tag/branch).
Then if your client makes changes you can compare the code they have to the code you sent them and easily spot the changes. After all if they feel the need to make changes there is a problem somewhere and you should fix it in the master codebase.
Another alternative for converting your program into a binary is the free PAR-Packer tool on CPAN. There are even filters for code obfuscation, though as others have said, that's possibly more trouble than it's worth.
I agree with the previous suggestions.
However if you really want to, you can look into PAR and/or Filter::Crypto CPAN modules. You can also use them together.
I used the latter (Filter::Crypto) as a really lightweight form of "protection" when we were shipping our product on optical media. It doesn't "protect" you, but it will stop 90% of the people that want to modify your source files.
This isn't a serious suggestion, however take a look at Acme::Buffy.
It will at least brighten your day!
An alternative to obfuscation is converting your script to a binary using something like ActiveState's Perl Dev Kit.
I am running a Windows O/S and use perl2exe from IndigoSTAR. The resulting .EXE file will be unlikely to be changed on-site.
As others have said, "how do I obfuscate it" is the wrong question. "How do I stop the customer from changing the code" is the right one.
The checksum and contract ideas are good for preventing the "problems" you describe, but if the cost to you is the difficulty of rolling-out upgrades and bug-fixes, how are your clients making changes that don't pass the comprehensive test suite? If they are capable of making these changes (or at least, making a change which expresses what they want the code to do), why not simply make it easy/automated for them to open a support ticket and upload the patch? The customer is always right about what the customer wants (they might not have a clue how to do it "the right way", but that's why they are paying you.)
A better reason to want an obfuscator would be for mass-market desktop deployment where you don't have every customer on a standing contract. In that case, something like PAR -- anything which packs the encryption/obfuscation logic into a compiled binary is the way to go.
As several folks have already said: don't.
It's pretty much implicit, given the nature of the Perl interpreter, that anything you do to obfuscate the Perl must be undoable before Perl gets its hands on it, which means you need to leave the de-obfuscation script/binary lying around where the interpreter (and thus your customer) can find it :)
Fix the real problem: checksums and/or a suitably worded license. And support staff trained to say 'you changed it? we're invoking clause 34b of our license, and that'll be $X,000 before we touch it'....
Also, read why-should-i-use-obfuscation for a more general answer.
I would just invite them into my SVN tree on their own branch so they can provide changes and I can see them and integrate their changes into my development tree.
Don't fight it, embrace it.
As Ovid says, it's a contractual, social problem. If they change the code, they invalidate the warranty. Charge them a lot to fix that, but at the same time, give them a channel where they can suggest changes. Also, look at what they want to change and make that part of the configuration if you can. They have something they want to do, and until you satisfy that, they are going to keep trying to get around you.
In Mastering Perl, I talk a bit about defeating obfucators. Even if you do things like making nonsense variables names and the like, modules such as B::Deparse and B::Deobfuscate, along with Perl tools such as Perl::Tidy, make it pretty easy for the knowledgable and motivated person to get your source. You don't have to worry about the unknowledgable and unmotivated so much because they don't know what to do with the code anyway.
When I talk to managers about this, we go through the normal cost benefit analysis. There is all sorts of stuff you could do, but not much of it costs less than the benefit you get.
Good luck,
Another not serious suggestion is to use Acme::Bleach, it will make your code very clean ;-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm about to start a project for a customer who wants CMS-like functionality. They want users to be able to log in, modify a profile, and a basic forum. They also wish to be able to submit things to a front page.
Is there a framework or barebones CMS that I could expand on or tailor to my needs? I don't need anything as feature-rich or fancy as Drupal or Joomla. I would actually prefer a framework as opposed to a pre-packaged CMS.
I am confident I could code all this from scratch, but would prefer not to, as something like a framework would significantly cut down on my time spent coding, and more on design and layout.
Edit: I should have been more specific. I'm looking for a Content Management System that will be run on a Debian server. So no .net preferably.
I think i may end up going with Drupal, and only adding modules that I need. Turbogears looks a bit daunting, and i'm still not quite sure what it does after it's 20 minute intro video...
TinyCMS doesn't look like it's been touched since... 2000?!?
I think the best is CMS Made Simple. Seems like drupal takes awhile to customize.
http://www.cmsmadesimple.org/
tinyCMS is about as barebones as you can get. (edit: fixed link, I had gotten a little click happy and linked to the wrong thing)
#modesty, I would definitely NOT use SharePoint, as it is anything but barebones. It is a fairly expensive product (especially when compared to the many free alternatives), and it has quite the learning curve to do anything interesting.
Woo, another Debian nut!
I think you need to be a bit more specific here, Forum != CMS. Is this for internal company or external customer use? What language(s) do you know/prefer? There's no point in recommending a Perl or PHP framework if your language of choice is Ruby. Do you need to plan for scalability?
What's wrong with Joomla or Drupal? I would argue that they can be successfully used on small sites. Maybe a framework isn't what you're looking for, maybe you just need a library or two (eg. PEAR?). If you need something smaller, maybe writing your own backend library that you can reuse for future projects would be a better solution.
For a one-size-fits-all framework have a look at Turbogears. ("it's a big hammer, that makes every problem look like a nail")
I've been obsessing over TikiWiki lately. Although it has "wiki" in the name, its full name is "TikiWiki CMS/Groupware" and it's an interesting piece of software. It has a real everything and the kitchen sink feel. It includes support for wiki, blogs, articles, forums, and files out of the box (and a ton of other stuff too). I think the real appeal to me is that most of the stuff can all be integrated together, wiki pages can include other wiki pages and articles (which is more useful than you might think). It's in RC stage for release 2.0 and is still missing a ton of features, but I think I might keep using it and contribute some of the features that are missing, it's a really interesting base right now.
The Mozilla support site is implemented using TikiWiki, for an example of a really beautiful implementation.
Drupal's include system should keep everything relatively lightweight as long as you only include what you need. Despite the fact that it comes with a smattering of modules, what you choose to enable is all that will be included at runtime. If you have to get under the hood and make modifications, I'm also a firm believer that Drupal is a more friendly and elegant system than Joomla. We use Drupal at my work-as much as a framework as a CMS-and it has proven pretty reliable in keeping development practices at a high level.
I realize I'm a couple years late to the party but I was looking for something like this myself and ran across this post while doing Google searches for 'barebones cms'. Along with this post, this turns up:
http://barebonescms.com/
There is also a forum on that site.
A similar combination could probably meet or exceed all of your criteria. Although, as others pointed out, you weren't particularly specific on the details.
While the original author is probably long gone, hopefully someone else finds this useful.
I would suggest PmWiki, it's something between a framework/wiki. By default there aren't even users, just different passwords, for different tasks, but using PmWiki Cookbook 'recipes' You can add additional functionality.
You can check their philosophy to get main idea what it's about.
If you want a Rails solution, Radiant CMS is a good option. It's simple, elegant, extensible and, of course, comes with all of the benefits of being based on Ruby on Rails.
if you are looking .net you can take a look at umbraco, haven't done much with it (company i work for wanted much more functionality so went with something else) but it seemed lightweight.
Edit : if the customer wants a tiny CMS with a forum, I would still probably just go Drupal with phpBB or simple machines forum, almost positive they can share logins. Plus tomorrow the customer is going to want more and Drupal might save you some work there.
Might want to check out Drupal.
Here are the details of the technology stack that it uses.
I have never used it so I can't vouch for the quality etc but definitely worth a look.
how about you use drupal but scale down and code it according to your needs.
definitely will be faster than code-from-scratch-with-framework
I have been working with Joomla for some time and I believe it one of the best CMS for starting off a Website. I have tried others a lot, But Joomla is better because it has Numerous Extentions (Components , Modules) and also its very Easy to Customize. You could also look at the Community Builder Extension for joomla.Other requirement like Chnage Fronpage Articles etc is a Breeze....
joomla.org
For some reason Joomla Does not Suit you try Drupal.
Wordpress is a very powerful but simple CMS.
bbPress is a very simple but integrated forum (easy, Wordpress user account integration with cookies and all).
Since you have programming experience you may find Wordpress to be the perfect match (PHP, MySQL) with plenty of plugins and hooks to help you achieve what you need. For example, there is a featured posts plugin that will put selected content on the front page.
I need to jump on the Umbraco bandwagon here. As far as ease of use from a developer standpoint goes, there is nothing easier than umbraco and v. 4 has full master page support and a tone of other stuff... and it's free.
For windows take a look at the DotNetNuke is asp.net based, free and open source and easily skinned and modified, there is also a thriving market in add-on modules. In addition most hosting companies offer it as a pre-installed application
Expression Engine is fantastic. It's free to download and try but you must purchase a license if you are making a profit with it.
WordPress actually has a forum plugin - it's nothing fancy but it's there. It handles user management et al and has a big community for plugins and themes. I think it is probably the easiest CMS to install & run (I've done some legwork here). There are plugins that update the core & plugins automatically (take that Drupal). I've tested these and they seem pretty solid. As usual - backup beforehand.
For .NET MojoPortal looks pretty good and is lighter than DNN. I saw the edit but thought I'd include this anyway since it looks like it's worth checking out.
Drupal is a language unto its own - I wouldn't tackle it unless you're going to do so with some regularity, otherwise it's just another different framework to learn. The uplink into my brain is at capacity already so I gently pushed it aside. The themes tend to look the same too.
Joomla may suit your users for usability.
I'd go for a pre-made framework myself because it would have a community and expansion capacity. What your client wants today will pale into insignificance tomorrow.