We are looking for a forum software we can integrate with our existing website. The most important thing for us is code quality and minimalism. Integration will be so tight, so we probably won't be able to update it in the future.
So far I can think of bbPress and Vanilla. Both have problems: the former is not actively developed (the last stable version was realesed a year ago) and the later one is very unstable (IMHO).
Any thoughts and suggestions are greatly appreciated.
Thank you!
There's MyLittleForum, which however is a forum software, not a bulletin board. Also you should use the still separately maintained 1.x version, as the new has more feature creep. The code quality is acceptable IMO. And you won't easily find a forum software which uses parameterized SQL or enforced input filters. (Been looking myself, Forum/Board written atop one of the big PHP Frameworks)
Related
We have a requirement to allow users to customise the CSS for a PHP app. In general, only that user will be able to view the custom CSS, but there are cases when other users in their group could also view the CSS, hence the need to ensure that its sanitized.
I am aware that HTMLPurifier and CSSTidy can be used for PHP, but CSSTidy is extremely outdated, and apparently can't handle everything that we need to throw at it.
I havent found any other PHP libs that can do this.
One alternative that I am exploring is taking a ruby library (http://apidock.com/rails/HTML/WhiteListSanitizer/sanitize_css or https://github.com/courtenay/css_file_sanitize/blob/master/lib/css_sanitize.rb) and converting it into php.
Before I go down that route, are there any alternatives to the above? And are there any pitfalls that I should be aware of before using one of the Ruby libs?
Update:
After almost eight years later, I wanted to leave a second note
because my answer start getting downvotes.
I am not dealing with JS/CSS anymore as much as my early career years. I
did mostly focus on building backend services and tools recent years. So, my knowledge on this subject may be outdated, even if I tried to keep it sharp, which requires discipline and hard work.
Neverthless, nicer tools may exist today other than HtmlPrufier and/or TidyCSS. I am not saying those tools are bad. But community support and active maintenance is important. As a thumb of rule, I am staying away from dead or unmaintained dependencies in my applications.
If PHP is a MUST here to sanitize, I would look into Wikimedia's CSS sanitizer first if it works for me. More or less, it's doing the job. Persisting a minified version of given CSS in filesystem, updating as modified on application side also would be a secondary goal for me. A pre-generated version could make my life easier when sending to browser. Any tooling would work there, PHP may just fire a dedicated event for it. Creating sanitized version of CSS may also be a background process candidate rather than generating on demand. Maybe via available tools from other platforms beyond PHP. So there are a lot more options and possibilities out there nowadays.
Hope my explanations shed some light for people trying to achieve something similar.
Original answer was:
HTMLPurifier and CSSTidy are right tools. CSSTidy still maintaining by Cedric Morin and few other developers on Github. Also default CSS level of CSSTidy is CSS3.0 since April 2012.
You may use that.
Hiphop from Facebook don't like eval() or create_function().
Are there good open source php-CMS which work with hiphop almost out of the box?
Drupal is not compatible as far as I know.
If possible, are those cms multi-site-enabled (one code base hosts several sites with different db-connection-strings).
I think that hiphop php could be a good choice for Amazon EC2 it could save a lot of money.
Thanks in advance,
Tom
Back in 2009, PHP creator Rasmus Lerdorf made a presentation for the Digg folks, in which he demonstrated numerous performance profiling techniques. It takes 20 slides to get there, but he demonstrated that conventional performance profiling techniques can be just as effective at increasing performance as HipHop.
Forget HipHop. Profile your code to identify bottlenecks, then remove them.
I apologise in advance as this is not stricltly a coding question, but, I wanted to canvass as wide a spectrum of opinion as possible.
I have been using hte Zend php stack (among others) for some years now mainly because htey offer the best ORACLE support and they offer commercial support which keeps my corporate clients happy (middle managers just love to spend!).
However recently I have been hit by two gotchas in a very short space of time. Firstly they dropped AIX support with no notice (I checked the version I wanted was available, checked the right version of Oracle was supported etc. two weeks later I went to download and lo - no AIX version). Secondly I was installing in a Windows 2003 server and the install hung, when googled the problem I discovered several people had the same problem going back to early 2008 -- but no solution was forthcoming.
Is it worth bothering with Zend anymore?
Personally I'm not interested in needs of business circles, but I have a humble opinion about Zend as a hobby coder if you're interested.
I had a quite deep investigation about PHP frameworks lately and reviewed the most popular one. Of course, big companies chose Zend Framework because of infinite requirements.
If you haven't managed to look at this framework, do so. You will find a big mass of ugly code which planned to be perfect in terms of programming habits, but in the end, it. just. doesn't. cut. it.
Zend is shown as the PHP company. They might know what PHP is, but have no idea what a company is.
I have looked at a good deal of other peoples source code and other open source PHP software, but it seems to me that almost nobody actually uses PEAR.
How common is PEAR usage out in real world usage?
I was thinking that maybe the current feeling on frameworks may be affecting its popularity.
PHP programmer culture seems to have a rampant infestation of "Not Invented Here" syndrome, where everyone appears to want to reinvent the wheel themselves.
Not to say this applies to all PHP Programmers, but them doing this apparently far too normal.
Much of the time I believe its due to lack of education, and that combined with difficulty of hosting providers providing decent PHP services.
This makes getting a workable PEAR installation so much more difficult, and its worsened by PHP's design structure not being favorable to a modular design.
( This may improve with the addition of namespaces, but have yet to see ).
The vast majority of PHP code I see in the wild is still classic amateur code interpolated with HTML, and the majority of cheap hosting that PHP users inevitably sign up for doesn't give you shell access.
In my (limited) experience, every PEAR project that was potentially interesting had major points against it:
Code is targetted at the widest audience possible. There are hacks in place all over the place to deal with old/unsupported PHP versions. New useful features are ignored if they can't be emulated on older versions, meaning you end up lagging behind the core language development.
Any given project tends to grow until it solves everyone's problem with a single simple include. When your PHP interpreter has to process all of that source code on every page hit (because the authors may not have designed it to be opcode-cache-friendly), there is a measurable overhead for processing thousands of unused lines of code.
Style was always inconsistent. It never felt like I was learning generalizable APIs like in other languages.
I used to use PEAR::DB at work. We discovered that most of our scripts spent their time inside PEAR code instead of our own code. Replacing that with a very simple wrapper around pgsql_* functions significantly reduced execution time and increased runtime safety, due to the use of real prepared statements. PEAR::DB used its own (incorrect at the time) prepared-statement logic for Postgres because the native pgsql_ functions were too new to be used everywhere.
Overall, I feel like PEAR is good as a "starter library" in many cases. It is likely to be higher quality code than any individual will produce in a short amount of time. But I would certainly not use it in a popular public-facing website (at least, not without a lot of tweaking by hand... maintaining my own fork).
Im my opinion PEAR is a good project but lacks people who want to work and keep working on it, most of the packages have inconsistent coding practices (I do not mean coding style) and there are lots of TODO's in the whole thing.
I find it useful sometimes for coding stuff I didn't know existed yet, like custom country validation functions and so on, otherwise I'm better served with any available framework out there (like CodeIgnite or Zend Framework).
The Pear library is the kinda stuff that just sits there, plugging away, with very little glory. If you are looking for something that it can do, and there's nothing more specifically targeted in the framework that you are using - go use it.
I've been working on a dating site for the last two years - and there's at least 65 pear-sourced files I've used, and are still live there today. Some, like the pager or html_Quickform will be overtaken by new code as it's updated, but for others there's just no need.
PEAR is not common, nor popular.
I tried to use PEAR so many times, but it lacks the umpphh to commit.
I prefer Zend Framework which takes the approach of 'loose' type, use only what you want.
PEAR is not common, nor popular — but it is good, and I'd recommend it to anyone.
(I do agree with Tom in that it doesn't feel like a single, unified, API; but then, this is PHP … one wouldn't like to see it getting above its station as an interpreted hack language now would one?!)
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 9 years ago.
Drupal is very much a "Do Everything" CMS. There are modules that allow you to add almost any functionality, which is great. However, it feels like a lot of the features (v5 and v6) seem scattered around and unintuitive for the user. As a developer, I'm left with the feeling of having patched a site together using bubble gum and string.
For example, to add text to the default search box (that disappears when clicked), you have to either add some jQuery code OR override the theme. I've also found the menu system more complicated than it should be.
Am I the only one with this opinion? What things (if any) would you change about Drupal's core?
To me, the biggest shortcoming of Drupal is that large portions of a live Drupal site are stored in the database. Since there's no automated way to migrate content or configuration between systems, rolling out changes to a live site must either be done manually or dealt with by excessively complicated code.
One of Drupal's biggest shortcomings is that it dances on the line between a turnkey tool for nonprogrammer site builders, and a framework for developers building complex webapps. It has some cool stuff to offer both groups, but the concessions to one crowd always tend to trip up the other.
The growing trend in the Drupal community is to explicitly build developer APIs, then layer administration UI and end-user UI on top of the APIs. This is a good thing, but there's also still a lot of legacy architecture. The project turned 8 years old this week, and every site requires a mix of modules that are evolving at different paces.
If someone hasn't already built a module that does what you want, effectively leveraging the system without hacking core code requires grokking a lot of different internal APIs, a lot of unique-to-drupal data structures, and studying up on some occasionally funky workflows. A lot of terribly bad and impossible to maintain sites are floating around in the wake of people who needed to do tricky stuff and didn't have the expertise (or the time) to research the "right" way to do things.
(Disclaimer: I just co-authored a couple of chapters for a book about Drupal, and I do Drupal work full-time, so I'm about as far from 'unbiased' as you can get. But I do like to think that I keep perspective. I heart Django, too.)
Drupal will get you 80% of the way there out of the box, but that last 20% will take months and months.
The lack of true object oriented design means that you frequently have to rely on other developers' foresight to leave "hook" functions to let you alter a certain behavior.
Using Drupal 5 I've also run in to situations where the only way to complete a relatively simple design change is to patch Drupal itself (and then be sure to reapply patches with each new official Drupal release). But, to be fair, you should have seen how bad it was in Drupal 4.
I'm also annoyed that when I take the time to identify a bug or quirk in the current production version of Drupal, I submit a patch, and the patch is never committed because, basically only security bugs get fixed in the current stable release.
Drupal is an impressive system. It's surprisingly small for all it does, and it's module system is extremely powerful. But as Eli said, a lot of your tasks are going to rely on other developers doing something in a particular way.
There's a debate within the Drupal community over it's design. Drupal was around before PHP's OOP features were strong, but now that they are, there's frequent discussion about changing the system to use object-oriented data structures. Depending on your tastes, this could be a downside to you as a developer. I'm of two minds about it myself.
The system can also seem to be very "magical" to newcomers, in that somehow it does all this crazy stuff with little explanation. "I only just defined a function, how the deuce does Drupal know how to call it?!"
However, I must say that in general I'm a big fan of Drupal. It's a good system that gets loads better with each major version. I for one can't wait for 7.
Drupal is good to get started but you spend more time 'undoing' than actually getting things done. This has been changing especially with the release of Drupal 6 and to be fair it's more apparent in contributed modules.
Managing migrations is also a problem as Sean said. I still don't know of a good method of moving changes from a dev site to a live one.
I am not sure there is anything I would change in the current core and most of the deficiencies are being worked on. Image management needs work, the default admin interface is a little cluttered making more complicated layouts without getting views/panels, etc. involved could use some work.
i find it awfully complex. as a php developer im tearing my hair out on a daily basis over issues that have nothing to do with php but with drupal itself. how / why / when does it do X? its a big beast that needs to be tamed. documentation is limited to a few very good guides, a whole lot of shitty ones, and even more useless forums threads that always seem to pop up in google.
usability on the backend is crap. a custom theme will also alter the layout of the "admin" part of the package which can be extremely frustrating and results in less than pretty layouts.
if you're working with html slicers, its impossible to use html that has not been created specifically for drupal. it pretty much forces you to use drupal-html, with lots of divs, 5 verbose classes per div, etc. by nature, html/css guys can not be expected to know drupal at this level.
i dont like the way it relies on filenames (10 words long, with very subtle differences between them) to build a theme.
having said that, some of the stuff it can do is very cool and saves you days and days of custom php development
Drupal gives powerful tools to Non programmers ,They can easily build up a full featured site with less time. But the problem is that learning curve is too high for Drupal.
If a person is new to drupal and want to make something customized it will take lot of time if he wants to do it in proper way. There are lot of ways to do a single thing in drupal,Finding out which is he best or proper for a new comer is a head ache.
I think it's high learning curve is the only shortcoming as most companies struggle finding good Drupal talent. http://drupalize.me/ and http://buildamodule.com/ are doing very good job to reduce this high learning curve.
I find that the default admin interface isn't very intuitive compared to other cms' like modx or joomla/mambo
It's written in PHP4. This will change as of version 7. You can write your own modules in php5 of course. As a seasoned Drupal developer and I find my resume has suffered due to my limited exposure to php5.
It's not the best for running services like SOAP. Calling the whole Drupal stack to provide a web service is too much of a performance penalty. The services modules are still in development.
No database transaction support. This becomes an issue when you scale it up to extreme loads.
It would be good to run tests from the command line. This was possible with simpletest 1.x but the current version doesn't support it very well. Simpletest is not mature enough. A clean Drupal install can fail tests. Some of the default included tests force you to use content types and modules you may not need and you can't disable these without hacking the simpletest module.
It has a seemingly bad security record: http://secunia.com/advisories/search/?search=Drupal