All you need to do is ensure that the undo option is highly visible (just like Gmail's; I've never caused irrevocable damage while using their web client).
With a little discipline and a better data model(cause basically it's using a meta table for everything that dont fit the core,"post meta" values are serialized strings ...lol with bother using a RDBMS at first place?), Wordpress could actually be good(codewise),it has some good business logic.
Wordpress maintainers just dont bother...because obsessed with backward compat.
Drupal is in my opinion (oddly) easier to maintain for non coders,CCK an Views, no need for any PHP skill to create new content types or write queries in Drupal.
With Wordpress,you need to code if you want to extend anything.
My problem with both is that the plugins are written in PHP.A good CMS would have at least one plugin layer which would rely on manifests(xml,json...) rather than code(just like angular),or at least have a sandbox system with permissions,some kind of inverted oauth system (eg:"this plugin wants to be able to write to your db,write to your file system,access this or that resource...")
Honestly, your characterization of Drupal is just plain BS, and I say that as someone who worked on Drupal sites for about 5 years, and am glad to no longer be.
To say it's less powerful than "plain PHP" is just wrong, since via custom modules, which you'll be writing at least a half dozen of for a real non-trivial (e.g. the kind of thing you wouldn't just do in WP, just you can essentially just sprinkle in 100% custom "plain PHP" whereever you need it, while still being able to leverage things Drupal does right, like form handling and batch operations.
i wrote drupal's form handling layer (and theme system, and big parts of drush and much more)
I ultimately found that I was happier writing stuff closer to the way wordpress does it.
It really comes down to two things
1. depending on what tools you have available, what you are familiar with or what you are capable of understanding .. drupal or wordpress might be easier for you than the other. That's relative.
2. is the fact that the wordpress model is objectively simpler than the drupal model (at least last time I looked, around 4 years ago).
So I'm not saying one is better than the other at all, just that this is how they are different.
If you know, or are willing to learn, a bit of code, wordpress is most likely subjectively easier than drupal would be.
I'm probably a bit biased because I spent most of that 5 years pouring my heart and soul into a site that was, basically, right up Drupal's alley, a regional news portal that was very content heavy. We did use lots of various modules, some core, and some community - such as polls, forums, captcha stuff, comments, we had almost a terabyte of stuff served via ImageCache...
We actually didn't use Drupal forms for much on the front end (The occasional webform for user submissions, etc, but very few actual drupal api forms), but on the admin backend we had lots of little things I threw together that worked well but were not used all the frequently (and then only by power users).
Our frontend was primarily done through a system I called the Page module (Because it was the module that made...the pages - for instance http://www.reflector.com/news). That was actually a really cool hack. It worked a lot like views - but could actually run on a high traffic site without bringing the whole thing to it's knees. The trick was that the really nasty join across about 8 tables (node, the content type data, related image data, story body (for teasers), and a couple others) was done only on node save and that was stored in an index table (not everything on the node, but just what I needed to build a page). So to generate each news block was a really super simple query of basically:
select * from page_index where page_blockid = 12345
order by updated desc limit 5
instead of something like, and this is the super simplfied version
select * from node left join content_type_story cts
on cts.nid = node.nid left join taxonomy_data td on
td.nid = node.nid left join uploads on uploads.nid = node.nid
left join upload_files uf on uf.uid = uploads.uid
left join node_content nc on nc.vid = node.vid
where (td.termid = 1231 or td.termid = 1256) and
node.published = 1 order by updated desc limit 5
(Field names ommitted because that query is way too long as it is).
Of course, we were running multidomain so a lot of those tables where domain alises etc, again, all precomputed in my module.
No, I don't miss it. But it was powerful, and I did develop, deploy, and serve 3 daily newspapers with 20k+ circ each with a dev and sysadmin staff of 1. There is no way I could have done that if I'd had to write everything from scratch.
That is a total mischaracterization of what it means for a language or DSL to be "powerful." When you are writing not-X to assist X in doing Foo, that doesn't mean X is powerful-enough to let you do Foo; that means that X isn't powerful-enough to let you do Foo without breaking out of X.
To put it another way: the fact that you can greenspun Lisp in C doesn't mean C has all the power of Lisp. It means that Lisp has all the power of Lisp. Every even-mildly-useful language is Turing-complete; so, in order to be able to give a ranking to languages at all, we have to restrict our discussion of a language's merits to its merits if you aren't just using it as a glorified Turing machine for implementing a different language.
Without writing custom PHP, Drupal is less powerful than PHP. That's perfectly okay.
I don't think so, since Drupal does many things that vanilla PHP is actually quite poor at - like getting away from the whole "each URL is a seperate file" thing.
Also, Drupal is NOT a DSL, even in the way, say, Rails is.
i'm going to respond to the sibling in here because I don't want it to get more nested. I also suspect it might be downvoted. (as some of your others have been)
I'm _intimately_ familiar with the feature. That feature came in with Drupal 4.2.0 back in december of 2001, which was the second Drupal release I deployed a site on. It was also the first Drupal release to include any of my own code.
Back in the day the only way to get anything committed was to roll a patch and commit it to a special cvs repository, manually numbering it. then you had to mail the dev list with the name of the patch so you could discuss it, and then if it still applied dries committed it.
I tried finding the mails on gmane, but the repo itself and the emails seem to cut out before.
So while q?= was considered an acceptable fallback, and it was still cleaner than what we had before ... this feature has always explicitly been about supporting url rewrites.
When I built bryght.com, my first startup in 2004, trying to be the wordpress.com of drupal, before wordpress.com was a thing : I had to make sure this worked with it.
When I wrote Aegir, a distributed turn-key automated hosting platform for Drupal sites, I had to write the logic that made sure this stuff worked. I did that for apache, and with some help from omega8.cc, nginx.
Please don't try to act like you're an expert on what 'design patterns' we were implementing when we did that, because I'm telling your straight out now, that wasn't why we did it.
I spent 9+ years of my life building major components of the system, and I'm still really proud of all of it. Millions of people all over the world run the software I helped build.
For one, Apache isn't even what I'd recommend to use for serving Drupal - at my last job we were serving 50M reqs/monthly via nginx and it worked very well.
Drupal implements the front controller pattern...it has nothing to do with URL rewriting.
It is true that if you want "pretty" URLs on Apache you need to use rewrites, but I think it is a cheap shot to characterize using a core feature as it was intended as a "hack".
The original assertion was that Z was more powerful than X, and I merely stated that that is false because X is really the superset X+Z, whereas if you are using JUST Z you don't get X.
We're not talking about 2 different languages here.
I'd argue that Drupal has been quite successful. It lost the war of platforms for blogs and, to some extent, forums, but has one a foothold for large projects which require a CMS. I'm not sure it was ever competing.
4.7 and 5.x (the first versions I used) didn't have many nice themes or a particularly friendly interface for content creators, which Wordpress had and won. But the Drupal community weren't much into making simple sites (though they could be made).
Drupal has always struck me as a CMS for non-coders to create something quite complex, and when scaling something for a coder to pick up and adapt as they need, with a lot of stuff built-in. And it has definitely won on that front, with perhaps the most comparable system being Django, but even then Drupal is more Swiss Army Knife like: It can't open a tin of beans perfectly, but it can do it quickly, and a few hours in the tool-shop improve it a lot. Likewise it can cut down a tree (if painfully), cut your fabric and has a neat nose-pick built-in.
Numerous media, government and commerce sites use it. It is quite adaptable, gets the 90% done quickly (yes, the learning curve is greater than Wordpress, but a lot more is happening), and allows anyone with some PHP and CSS expertise get the remaining 10% done reasonably well.
I don't agree. I realized a intranet content /document management system with Drupal 6 a couple of years ago in just few months. It was used then by 500 users with great results and I used available modules except for one that I hacked together for integrating authentication with lob webapp.
I'm not a developer (sysadmin) even though I know some coding and I could not have deployed it with all those features in the same time developing it from scratch with php (or any other languages).
The most of the time I spent was trying to "port" the designer's photoshop draft in a Drupal theme (it would have been better to have an external guy/company do it). Rest of the time was finding the right modules (there are too many on the site) and then understanding the pain point of the previous system can thinking something better (but that analysis part should happen with any technology involved )
I would suggest that it's not quite so linear anymore with the rise of ProcessWire. I'd compare ProcessWire to WordPress for ease of use and Drupal in terms of flexibility and scalability – I didn't think it was possible, but it is.
> "But in our universe, people saw the algorithm as hackneyed, particularly when Justin Bieber had a higher Klout score than the US president."
Maybe Klout was wrong with this particular arrangement, or maybe your assumptions about who has more influence are wrong. Ever thought about that?
After all, "entertainment clout" can be very quickly capitalized as "political clout", as Mr. Terminator has demonstrated.
When it comes to selling products, whose endorsement will sell more products: Justin Bieber or the US President?
Remember Klout's score is used to give "perks" to influencers, the purpose of which is that they show those perks to their fans, therefore influencing them.
While I don't care about Klout at all, I have to say I'd rather bet on Justin Bieber than the US President for that specific purpose.
I respectfully disagree with your argument because that's not the one I'm making.
I think the general consensus from Klout detractors is that a single "score" cannot encompass someone's influence. Some people are more influential in certain circles than others.
Of course, there is a broad-based influence score you can apply to people, in the same manner that Super Bowl ads are expensive because they reach a broad-based group of US TV viewers. If Justin Bieber reaches that group better than President Obama, than his higher Klout score is accurate.
But under that assumption, his Klout score (and many other Klout scores) are meaningless because we don't think of ourselves in that context. This is why, for example, HackerNews karma points are not fungible to Reddit's /r/AdviceAnimals karma points.
Any system which one party creates for a set of players will effectively be gamed by a more willing and able actor.
> Given all our activity (direct or indirect) that is being captured on social networks and general internet activity, there was some inherent value (which we'll call a "clout score") in just knowing who was the "most popular" on these networks.
This as I understand it, is your argument on why Klout should exist. To paint an even simpler picture, this effectively determining a signal-noise ratio for people. Unfortunately, this is flawed, because I believe that we as human beings cannot even determine our own signals. Ultimately we have to rely on 3rd party actors to do it for us (call them Mavens, pundits, curators, or what have you). More of my own thoughts on this: http://www.techdisruptive.com/2012/09/18/we-are-far-from-sol...
Not my argument. If theoretical Klout existed, it'd take into account all signals (social, search, semantic analysis, weights based on expertise, etc.) to determine the "best" at something--a super pagerank for people search if you will. This should negate individual bias.
> a single "score" cannot encompass someone's influence
I would argue the opposite. There is one ultimate "score" of a person's influence: their wealth.
While not all of a person's influence is delimited in dollars at any given time, almost every kind of influence is fungible to dollars. You can, for example, "spend" social capital by burning bridges asking friends for personal monetary loans.
It's actually pretty unclear to me whether President Obama's or Justin Bieber's influence would liquidate into a greater amount of money. But it's certainly a question that has a factual answer, and it's a useful answer, unlike a Klout score.
In a nutshell, social engineering can be countered by proper software & processes engineering.
So if social engineering is possible, blame the software architects.
Maybe in extreme cases changing the email of an account might be needed, but there's no excuse a first level rep was able to do it. Least thing, he/she should've been forced by the system to escalate to someone above her, who has a much lesser chance to screw up.
They didn't say it was first-level rep. Maybe the rep passed it up the chain.
This was a pretty weak request, though. This one should have been pretty easy to at least make some attempt to verify.
But as a human being I can verify how hard it is to not help the person crying on the other end of the phone because they need help RIGHT NOW. This didn't get to that level, but if you are designing a recovery process, you really need to think about how you handle that situation, and make sure the people making the call have the guts to say "I'm sorry but we need to do this one by the book."
I'll talk it over with my group. Retraining doesn't guarantee anything. It could be that this problem is endemic to the company itself.
For example, why should 1st level support have the ability to make major changes like this? It sounds like only 2nd level support, a smaller group of more highly trained support staff, should have the ability to do this. Does SendGrid have enough money/resources to split their team into 1st and 2nd level support? Would a larger company have those type of resources that would better protect my customers?
These are questions I will talk over with my team.
The fact the Sendgrid even has to do re-training in the first place is the problem. They only need to do and handful of things well and keeping their users accounts secure is arguably the most important. If they are having issues like this this far along in their lifespan, it's a sign of more systemic issues in their company and does not instil much confidence to potential/current customers. Wanting to switch vendors doesn't seem weird at all to me.
I think you're being lenient with SendGrid because it was a close call and not a full-blown catastrophe. First of all, SendGrid lied about its support staff's permissions. After the incident, SendGrid then sends an "oops! our bad!" e-mail where the employee in question will apparently be gently tapped on the wrist and maybe send a passive-aggressive reprimand.
I mean, keep in mind that this is the same company that publicly crucified a female employee in order to stop a DDoS attack. Clearly there are some priorities out of whack there, and given the insecure nature of e-mail in the first place, I would never want to deal with a company that is so clearly unprofessional.
It's hard to argue that Java's OOP model is bad. It encourages clear code structure and works especially well for large project (for tiny projects you don't need OOP at all, anyway). This is why C#, PHP, this library and many more are based on Java.
And a bunch of people coming out of their caves to tell us how JavaScript's quickly cobbled up hacky prototype system is a design by God himself, and everything else is the Devil trying to trick us into his Java ways... Sigh.
Which is why the next versions of JS (ES6 and ES7) will have:
1) Modules (namespaces)
2) Classes
3) Member visibility
Whoops. Ignore the cognitive dissonance and continue with the flame!
Now. While the library linked here isn't the prettiest thing I've seen, I immediately get it. And I can immediately start coding in it and get the expected behavior.
This, in itself, is a huge feature compared to the awkward incantations one has to do in barebones JS to do OOP (of any kind). Even the fact it's string based doesn't make it inferior to some of the other unreadable stuff I've seen by people doing JavaScript "properly" (or so they think).
So, I say kudos about that. Here we have an implementation solving a practical problem in a practical way. No plot twists and surprises.
I prefer TypeScript, but this one doesn't require a parser, so it has its benefits.
I assume this message is aimed at me.
I'm not worried about ES6. ES6 classes are just syntactic sugar over prototypes, so it'll still confuse the FUCK out of java, c#, c++ and flash developers, because they are still SEMANTICALLY weird and confusing to people used to classical inheritence.
So I'm happy about that. As long as Java developers are unhappy with something, I likes it.
The awkward incantations you speak of are indeed awkward, I will admit.
I mean, how fucking confusing is
Object.create({ your prototype here });
am I right? This is much better:
MySpecialFramework.extend({ my prototy.. .*ahem* class here! })
That private API is called a service layer, and without it, your code devolves into copy/paste spaghetti.
We live in an age when having a complementary iOS/Android app for your site is not the exception anymore. Without a service layer you'll have coupled your services with your web pages. Connecting your server with your apps will be quite painful. You don't want that.
Done right, your service layers keeps your code simple, secure, and easy to debug, even if it's web-only. I'd argue that anything else is just due to lack of experience.
A service layer also makes the work on a project more parallelizable in terms of number of developers that can work together on it, each focusing on their part of the puzzle, without breaking each other's code all the time.
But then your service layer has potential SQLi issues. Moving the problem doesn't make it go away. Many of the clojure SQL libraries solve this by using prepared statements by default. This is not a hard problem.
If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way?
And moving the problem actually helps, when the original place was the wrong place to solve the problem.
Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance.
In a service layer you have exactly three concerns:
1) Validate abstract input (and permissions of the caller).
2) Perform the transaction.
3) Return abstract output (and/or errors).
No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing.
Just input, transaction, output. Pure data. Pure business logic.
And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer.
All your iOS and Android app code - also calls the same service layer.
And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service.
And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi.
I've seen SQLi blindly passed from frontend code to a backend service API and then executed. The indirection did help mask the issue so there was no suggestion the attack succeeded or way that it could actually be exploited, but it's perfectly possible to what you describe without actually solving the sanitization problem.
SOA is great for scalability, but not really that much of a boon for security (especially since you now have a problem of authentication between your frontend service and your backend service which is often ignored since it's behind the firewall and nobody is going to be snooping.) (Other than the NSA, GHCQ, and China.)
You can always shoot yourself in the foot even with a service layer.
But in a service layer you need to get it right once. And therefore if you don't, you have to fix it just once.
And coupling your business logic with your frontend layer suggests spaghetti code and violates DRY, because you typically have many frontends, but one app state.
Security is about focus. If the service coders can focus on the service being secure & fast, frontend guys can focus on the frontend being usable.
Otherwise you're asking everyone to think about everything, and human attention span, memory and skill sets are limited, and this does affect security.
OK, Django ORM, conditional aggregates - these were not possible last time I checked. You can do it at the application level, but say you want to keep the performance up, you need to drop into SQL.
