Oops! The worst has happened: your Drupal site has been hacked! Maybe it was precisely one of those critical vulnerabilities, that the Drupal security team has been drawing attention to these last months, that the attacker(s) exploited?
Now what? What to do?
Should you be:
rushing to restore your website to a healthy, good-working state (that, of course, if you do have a clean and recent backup available)?
starting to rebuild it?
investigating how your Drupal site got contaminated in the first place: where's the “open door” that the attackers used to get in?
focusing on closing any backdoors that could make new attacks possible?
Now “tormenting” yourself with too many questions simultaneously will only distract you from what should be your main objective: cleaning up your website (and preventing further hacks I should add).
So, let's go about it methodically, step by step:
Step 1: Write Down Issues, Steps to Take, Preventive Measures to Apply
Keep your cool and go for a methodical approach to crisis management:
Just open up a document and start... documenting:
the issues and any suspicious activity that you identify on your site
all the steps that your strategy for removing malware and restoring your site should include
the preventive security measures you commit to taking for preventing such a scenario from happening again the future
Step 2: Make a Forensic Copy of Your Drupal Site
Before you start running your “investigations” on the attack, on how your Drupal site has been hacked, and way before you get to rebuild anything:
Make a forensic copy of all your files, you database and your operating system environment!
Note: go with an external storage medium for these copies and store them offsite.
As you're scanning through your files, detecting viruses and malware and having them cleaned up, feel free to make new and new “working backups”. And to store them in a different directory (from your regular backup files, I mean).
“But why bother? When will these backups turn out particularly useful?”
when you call out to a third party to assist you with the troubleshooting process; these “working” backups will then provide a clear picture of the site before you started “malware detecting” on your own
when you try to fix the issues you detect, but instead you make them worse; then, you can easily roll back those changes
Step 3: Scan Your Servers and PC for Malware, Malicious Code Injections, Viruses
Before you rush to change all the passwords on your site, pause for a moment to think through your next “move”:
What if the attack has been “programmed” so that the attacker should get notified once you change your password(s)? And what if it's precisely your PC or one of your servers that's got infected? Then storing a clean backup of your site precisely there would only make it even more vulnerable.
So, how do you prevent that? You give both your PC and your servers a deep scan before making any change.
And, thank God, you sure aren't nickel and dimed in anti-malware tools and anti-virus software: AVG, BitDefender, Malwarebytes, ESET, AV-Comparatives etc.
Step 4: Detect & Remove the Backdoors
One of the crucial steps to take, once you realize that your Drupal site has been hacked, is to “close” all the backdoors.
These could easily turn into hackers' access ticket into your site even after you've removed malware and restored it to its healthy state. But, for closing them you first need to... find them right?
So, where to look?
Here are a few key places on your site that you should focus your “searches” on:
access logs: while scanning them, be vigilant and look for PHP scrips and POST requests added to directories that have writable access
eCommerce set up: check all the payment methods, shipping addresses, credit card addresses, linked accounts, looking for any suspicious, newly added data
passwords: FTP passwords, admin passwords, control panel passwords
email rules and filters: check that the answers to the security questions are “legitimate”, that messages are being forwarded to correct email addresses etc.
Step 5: Consider Taking Your Site Offline
And your decision depends greatly on the nature of your site:
If it's a hacked eCommerce Drupal site that we're talking about here, then don't wait even one more minute: take your site down (along with the internal network and servers) and install a placeholder!
This way, you'll prevent:
malware from being further distributed
spam from being sent to your online store's customers
Note: do keep in mind that taking your site offline will instantly let the attackers know that you've detected the malware that they've “infiltrated” and that you are about to “take action”.
If you decide not to take your Drupal site offline at the web server level, ensure that you've got your clean forensic copy at hand before deleting all the sessions.
Note: have you detected suspicious changes of the passwords? If so, use this query here for updating them (Drupal 7):
update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))))
As for the users, they can easily use the reset password tool for updating their passwords.
Word of caution: mind you don't take "Drupal on maintenance mode” for “offline Drupal". They're 2 completely different things! Once your Drupal site has been hacked, the malware could be of such nature that it allows the attacker to infiltrate as long as the site's online.
Step 6: Notify Your Hosting Provider That Your Drupal Site Has Been Hacked
They should be informed about the breach and about your site being taken offline (if it's the case) immediately.
The sooner the better, this way they can:
start scanning their own systems for incursions
get ready to assist you with your site recovery and securing process
Step 7: Handle Client Data with Extra Precaution
And these are the specific scenarios where you'll need to take extra precautions when handling client information:
your Drupal site stores client information on the web host
… it leverages the data POST method for sending form data via e-mail
… it doesn't integrate with a 3rd party payment gateway, but manages the payment processes itself
If one of these 3 scenarios suits your case, then here are some of these extra precautions that you need to make to ensure the private user data doesn't get exposed:
update your SSL certificate
re-check all logfiles (have any of the hosted client information been copied, updated or downloaded?)
implement AVS (address verification system)
add CVV (card verification value)
encrypt connections to back-end services used for sending confidential user data
Step 8: Investigate the Attack: Identify the Source(s) of Infection
No matter how much pressure you might find yourself under to get your site back online ASAP, don't let take control over your site's restoring process!
Not until you've detected the main source of contamination on your site. The key vulnerability that attackers exploited, the key reason why your Drupal site has been hacked in the first place.
That being said, make sure that:
you first audit, on a staging server, that “clean” backup of your site that you're planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code
you compare pre- and post-hack files, looking for any suspicious changes
Now if you have a clean (and recent) backup at hand for running this comparison, the problem's almost solved. Just use the right tools to compare your files and track down discrepancies.
But if you don't have a backup at hand, then there's no other way but to:
Manually inspect your files and databases to identify any suspicious changes that have been made.
look for any suspicious iframe or JavaScript at the end of the files (if detected, save the code in an external file)
look for any sources of “Drupal site hacked redirect”; for links to external URLs
Now, as for the places that you should be running your investigations on, let me give you just a few clues:
.php files, .html files
sessions table
newly modified/created files
new/updated user accounts
in writable directories and database
Step 9: Do a Full Restore of Your Site
So, you've noticed that your Drupal site has been hacked, you've assessed all the damage caused, removed malware and even detected the vulnerability that hackers exploited to get in, not it's only but logical to:
Try to repair your website, right?
Word of caution: never ever run your changes on your production site; instead, fix all detected issues on a staging site. Also, once you've cleaned it all up, remember to run the latest Drupal security updates, as well!
Now, getting back to repairing your site, you have 2 options at hand:
you either restore a clean backup, if you know the date and time that your Drupal site has been hacked and you're also 100% sure that none of the system components, other than Drupal, got contaminated
or you rebuild your Drupal site
The latter method is, undoubtedly more cumbersome, yet a lot more cautious. Go for it if:
you do not know the precise date and time when your site's got contaminated
you do not have a clean (and recent) backup available to restore
you've evaluated the damages as being already too widespread
Step 10: Give Your Restored Site a Full Check Before Going Live
Do remember to give your newly recovered site a final audit before getting it back up:
remove all malicious code detected
suspicious files
unauthorized settings
And, most of all:
Close all the backdoors!
Final Word
A pretty long, complex and discouragingly tedious recovery process, don't you think?
So, why wouldn't you avoid all these steps that you need to go through once your Drupal site has been hacked?
Why not avoid the risk of finding yourself forced to take your website offsite for... God knows how long, risking to impact your site's reputation and to drive away users/online customers?
Don't you find it wiser to:
be prepared instead?
opt for ongoing Drupal maintenance and support services?
make a habit of regularly backing up your website?
keep your system and software up to date (and to install all the recommended patches)?
stop underrating the security advisories that the Drupal team makes?
RADU SIMILEANU / Jun 25'2018
If only there was a... button that you could just press to convert your app to Android or iOS, right? Or if only a quick and easy recompilation process had been enough. Or if the “Let's just make it look similar” approach was your “winning card”... There is no such thing as “easier way” to port an Android app to iOS and vice versa.
Instead, there are essential aspects to consider and to adjust your whole app porting process to, meant to stir you in the right direction:
navigation
design considerations/UX
screen size and resolution
code and essential app architecture differences
3rd party services, frameworks, extensions, and used libraries
And, as you might just guess, the list is incomplete. For it includes other factors, as well, such as device support, customer and business model considerations and so on...
To keep your app's architecture intact, while porting your app between Android and iOS — 2 platforms with drastically different UIs and core structures — considering the above-mentioned 5 factors becomes crucial.
Therefore, let's detail them, shall we?
But What Does App Porting Actually Mean? Its 4 Key Stages
Let's start with some sort of definition of the whole process:
By porting your mobile app you're changing or rewriting its code so that it should work on a different mobile OS than the one that it's been initially developed for.
Clear enough?
“How long does it take to port an Android app to iOS and vice versa?” you might ask yourself.
Usually from 1 to 6 months, but it depends greatly:
on your app's complexity
on its core architecture
on the entire ecosystem of libraries that it uses, on its design particularities
on the business logic behind
Speaking of which, analyzing precisely the driving business logic is as critical as it is underrated by developers who usually stick to: adapting a platform and eventually writing the needed extra code.
“And what are the essential steps to take to porting my app?”
Glad you asked. Here are the main stages that an effective mobile app porting process should include:
analysis and plan
technical assessment
the porting itself
intensive QA
1st Factor to Consider When You Port an Android App to iOS: Navigation
Navigation is the factor that "miles" sets apart the user behavior on Android phone from the user behavior on iPhones.
Here's why:
Android devices are equipped with 3 different buttons: Home, Back and Multitasking button
iPhones only have the home button
Now, imagine tapping a multitasking button as in the Android platform: you can't get away with a simple transfer to iOS. Instead, you'll need to write the proper code for it from scratch.
And there's more to navigation and to the way that it is drastically different from one platform to the other. For instance:
Both horizontally and vertically displayed elements on iOS vs vertical elements only, on Android devices.
Tip: if you wish your iOS app to look similar to its Android alternative, there's always the handy compromise that you can make of placing in-app tabs in the bottom of the screen.
2nd Factor to Consider: Design Considerations/UX
You'll have to reconstruct your app's user interface from scratch to convert it from Android to iOS (or the other way around)!
Face it, deal with it and... adapt your “battle plan” to it!
There's no way around this:
When it comes to UI, Android and iOS are just... worlds apart! Android taps into material design, contrasting Apple's signature flat design.
Now here are the key design elements that you should pay special attention to, along with some tips on how to make their porting... smoother:
icons: each platform provides you with its rich icon library
dialogs
font styles: San Francisco or Helvetica Neue in iOS and Roboto in Android
content navigation
lists
object placement: flat vs hierarchical object placement
text alignment: center aligned test in iOS vs left alignment of the text in Android
buttons: iOS “favors” flat buttons with shadows, whereas in Android you'll find both flat and floating action buttons
Word of caution: when porting apps to Android or from Android, keep in mind the pixels vs points (pt) difference when it comes to measuring icons and font sizes in the two platforms
3rd Factor to Consider: Screen Size and Resolution
Briefly put: it will be conveniently smoother to port an Android app to iOS than vice versa.
Why? Because in Android you have a varied collection of screen sizes and resolutions at hand, whereas in iOS it's significantly lighter.
So, if it's an app porting to Android that you're planning, do take into consideration all those screen resolutions that are missing in iOS.
4th Factor to Consider: Your App's Essential Architecture
And here's the right approach to adopt when you port an Android app to iOS (or vice versa) and you're preparing to build its new architecture:
Identify the minimum OS version that your ported mobile app should support and set up its architecture accordingly.
5th Factor(s) to Consider: Frameworks, Libraries, Extensions, Code
Your current app's “infrastructure” of libraries, extensions, 3rd party services and frameworks play a critical role.
A “too critical role” not to turn it into an essential factor to consider once you decide to port your app to a new OS.
Therefore, for each one of the used libraries that's not compatible for cross-platform usage you'll need to find a suitable equivalent. And it goes without saying that this calls for:
A proper testing of each given framework and 3rd party library, to know for sure which ones support both OS and which ones don't.
The good news is that most of them do support them both, making it smoother for you to duplicate most of your app's basic functionalities when converting it to another OS.
Now when it comes to the aspect of code, the fact that the 2 platforms use different programming languages influences greatly the way you should port an Android app to iOS:
Kotlin and Java are used for building Android apps, whereas Swift is used to develop iPhone apps. Therefore, you can't get away with simply compiling your app's current code into its new ported version.
Note: I know what you might be thinking, that both OS support the C-code instead and so, that you could transfer your codebase to the other platform. Yet, it has already been proven that porting apps to Android from iOS calls for a complete rewriting in a different language.
How long would it take you? It depends greatly on your app's feature set, on the used 3rd party libraries, complexity etc.
Final Word
As you can see, once you decide to create a “clone” of your iOs app for the Android platform or vice versa, you'll need to take “recompilation” out of your mind.
Porting your app won't be that simple!
With the 2 platforms having completely different user interfaces and core structures:
careful planning and in-depth analysis (and yes, I'm thinking business logic here) becomes crucial
taking into account all those elements that set these OS worlds apart (interface, navigation...) and adjusting your porting strategy accordingly is the only effective way to port an Android app to iOS or vice versa
Adrian Ababei / Jun 21'2018
“Mysterious” pop-ups that you did not initiate, inexplicable auto-linking keywords, frequent freezing of your website... These are all but clear signs that your WordPress site has been hacked! Now what? Where should you look for the “infection”? Here's a step-by-step guide on how to fix a hacked WordPress site.
And it goes without saying that the very first step to take is to:
Keep calm!
Next, you'll need to figure out how precisely that malicious individual has found his/her way into your site. What security vulnerability has he detected and exploited?
Once you've determined how your WordPress website's got hacked, figuring out how to remove the malware is already a half-solved problem.
So, let's dig in before this hypothetical infection has spread out throughout your entire website:
Step 1: Identify the Hacked Files (and Change Your Password)
Remember what we've already agreed upon, that the very first step to take is precisely not to panic?
So, while keeping your cool, start your “investigations” by asking yourself 3 key questions — this, of course, after you've already asked yourself “How to remove malware from my WordPress site?”:
Are you able to access your admin panel?
Is your site already marked as insecure (by Google)?
Is your site redirecting automatically to another website once you log yourself in?
At this point, I also strongly recommend that you changed your password, as well. And this before you jump to the next step of your investigation.
Note: remember to change it again after you've cleaned up your website, as well.
1.1. Give Your Site a Thorough Scan Using a Security Tool/Plugin
And I do think that it never gets redundant for me to stress out:
Turning on a powerful WordPress security plugin on your website is one of the best shields that you could activate around it.
In case of an emergency situation, like this one here, you'd simply enable it to scan your site remotely and track down malware locations and malicious payloads and, most of all:
A good security plugin would identify and alert you, in real-time, of all the changes made to your website.
Note: everyone knows it, yet most website owners stubbornly ignore the importance of keeping their loads of WordPress themes and plugins updated regularly. They just overlook the fact that out-of-date files are by far hackers' “top favorite” security vulnerabilities.
1.2. Check Whether Your Core Files Have Been Compromised
And since they're by far the most valuable files on your site, it's only normal to check their integrity first things first:
wp-includes
root folders
wp-admin
Most of these core files should never ever be modified.
And there are 2 ways of checking them:
you either use the diff command in your terminal
or you check them manually, via SFTP
If they're unchanged and therefore clean, move on to the next step of this “how to fix a hacked WordPress site” guide:
1.3. Check the Integrity of the Recently Modified Files
It may also be that precisely the recently modified files on your WordPress site are the “corrupted” ones.
To know for sure, identify the files that have been recently modified.
And again, you have 2 options at hand for this type of “investigation”:
the manual check
running the right commands in your Linux terminal
For manually identifying these newly changed files that might have been hacked just go through these steps here:
log into your server (use the SSH terminal or an FTP client)
if it's SSH that you're using, then it's this command that will automatically list all the files that got modified the last 15 days: $ find ./ -type f -mtime -15
if it's SFTP that you're using, just scan through the last modified date column for all files on your server
… detect any files that recent changes have been made to
Now for tracking down these possibly “infected” recently modified files using the terminal, just follow these 2 simple steps:
run this command in your terminal: $ find /etc -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort -r
next, if you want to identify the directory files, enter this command: $ find /etc -printf '%TY-%Tm-%Td %TT %p\n' | sort -r
Are there any unexplainable changes made to those files in the last 7-30 days?
1.4. Check the Diagnostic Pages
A conveniently handy way to remove a virus from your WordPress website is to “track it down” using Google's or another website security authority's tool to give your site a deep scan with.
Has yours already been blacklisted by one of these authorities?
Then simply run the Google Transparency Report:
go to Safe Browsing Site Status website
enter your website's URL there
check both the Site Safety Details and the Testing Details sections
It's a quick and easy way to collect valuable information about any suspicious downloads, redirects, and spams on your site, as well as priceless data about Google's recent scan that ended in malware being detected.
Note: another way of identifying malware that's within your reach is by using a free webmaster tool — Google Webmasters Central, Norton SafeWeb, Bing Webmaster Tools etc.
Step 2: How to Fix a Hacked WordPress Site: Removing the Detected Malware
After all your preliminary investigations, you should put together your battle plan for actually removing the identified hack from your WordPress site. And for restoring it to its pre-hack clean state, too, obviously.
For this, here are the most effective measures at hand for you to apply:
2.1. Is a Clean Backup Available? Use It to Compare Pre-Hack to Post-Hack Files
Is there any need for me to stress out that:
You should back up your website on a daily basis!
And the very situation that you're in now is by far one of the strongest reasons to do that:
“How to fix a hacked WordPress site” will get reduced to: “simply comparing a clean backup to the current hacked version of your site!"
Identify the files that have been modified and get them removed.
It goes without saying that you risk losing some of your files — those added/updated after the last backup — but you do want a clean website now, don't you?
2.2. Remove the Identified Infected Files from Your Website
Once you've restored your WordPress backup, you can easily remove any suspicious plugin, theme or other types of file.
Note: do handle core files with utmost caution, though! Mind you don't accidentally overwrite your wp-content folder or your wp-config.php file.
When it comes to infected custom files, you could replace them with a clean recent backup or with fresh new copies.
“But how do I remove “malicious” code manually?” you might ask yourself.
Let me go briefly through all the key steps required:
log into your server (via SSH or SFTP)
back up your website
track down the recently modified files
replace any suspicious files with copies from the WordPress repository
use a text editor for opening up any custom files there and remove any suspicious code that you'll detect
test your newly cleaned up website
Word of caution: manually removing a malware infection from your WordPress site does call for special safety measures. Never remove corrupted code without first backing everything up!
2.3. Remove All Malware Infections from Your Database Tables, as Well
Now, you do agree that a “how to fix a hacked WordPress site” tutorial couldn't possibly skip the step where database tables get cleaned up of any malware infection.
Here's how you do it:
connect to your database using your database admin panel
create a backup of your database
give it a deep scan looking for any suspicious content
if detected, open the table containing that specific link or spammy keywords
manually remove that infected piece of content
give your website a “post database clean up” test
remove any tools that you might have used specifically for this operation — Adminer or maybe Search-Replace-DB
2.4. Check All The User Permissions: Look for New, Unfamiliar User Accounts
My advice to you, when it comes to user accounts, to user roles and permissions on your WordPress site is to:
Keep just one single admin user and stick to the essential user roles (and granted permissions):
author
editor
contributor
etc.
This is one of the most effective prevention measures that you could take so you don't end up asking yourself “How to clean up a hacked WordPress site?”
Now, coming back to our investigation here, here's how you remove all the unfamiliar WordPress user accounts from your website:
first, back up both your site and your database
log into your admin panel and click the “Users” tab
track down any unfamiliar new user accounts there, hover over them and delete them
Note: another wise thing to do is to re-check each user's roles and permissions. If you feel like updating them, simply use the users' role editor plugin.
2.5. Detect and “Close” all the Backdoors
And you want to treat this aspect with maximum seriousness. Otherwise, following each and every step indicated to you in this “how to fix a hacked WordPress site” tutorial becomes... pointless.
For the attackers would always have this “secret passage” to infiltrate themselves into your website over and over again.
“But what are backdoors more precisely?” you might ask yourself.
They're files similar to your site's core files — wp-config.php and key directories such as /uploads, /themes, /plugins — yet strategically placed in the wrong directories.
Here are some PHP functions that you could recognize them by:
str_rot13
assert
base64
move_uploaded_file
eval
system
stripslashes
gzuncompress
Word of caution: keep in mind that there are plugins on your WordPress website that could be legitimately be using these PHP functions; therefore, make sure you test all those "apparently suspicious changes" before rushing to remove the so-called "malicious" functions. Otherwise, by removing benign functions, you might just break your website.
2.6. Request a Review of Your Site, to Have all Malware Warnings Removed
Now, once you've repaired all the damage caused on your Wordpress site, it's only but logical to... let the blacklisting authorities know that your site's clean now.
For this, you can just request a review of your recovered website.
2.7. Change Your WordPress Salt Keys
The very last step to take in this “How to fix a hacked WordPress site” process is to change the security keys from your wp-config.php file:
This way, even if a potential attacker stole your password, he would get automatically auto-logged out once you've changed your WordPress salt keys.
Next, you can just change your password, as well as the ones of other users on your site.
Or, Just Cut All These Steps Down to a Single One: Preventive Maintenance
Which means adopting a WordPress maintenance and support plan tailored just for you and your specific security feature needs.
This way, not only that you'd save the time (and spare your nerves) that you'd otherwise invest in carrying out all the steps included in a tedious “how to fix a hacked WordPress site” process, but:
From running regular updates to on-going maintenance of your website's core components to regular security audits, you wouldn't need to... move a single finger. Our WordPress maintenance and support team would handle it for you.
“Prevention is better than cure” is so much more than just a saying...
Adriana Cacoveanu / Jun 19'2018
Sorry to disappoint you, but: there's no such thing! No such thing as “the best way to style React components”. Or “the most effective approach” or “the currently best option” for styling reusable components within your application.
What you do have, instead, is:
“The most popular or commonly-used ways of styling components!”
4 of them, actually.
And rating one of these approaches as “the best” is totally up to you:
to your personal preferences
to your React app's level of complexity
to what precisely it is that you need to style in your React project
and to your feature needs
Is it just a few style properties that you need to add? Then the inline styling approach suits your “component styling scenario” perfectly.
Or maybe it's a more complex React app that you're working on? In this case, you might want to go for the classic approach: using CSS classes and stylesheets and tying them all together with webpack.
But let's just put each of the 4 popular ways of styling React components into the spotlight and clear the picture for you a bit more!
I'll be highlighting each option's main advantages and drawbacks, so you can knowingly decide which one's the best option for you.
1. The Classic Approach: Using Regular CSS Stylesheets
You always have classes and stylesheets to rely on when it comes to styling. Simply tie them all with webpack after you've imported CSS file:
import './DottedBox.css'
… ensuring, this way, that you have a separate CSS file for each one of the components to be styled.
The main advantages of this common approach?
it'll then be easier for you to move between your CSS and the browser
it will streamline overriding or MVT in case you'll need to go in that direction
Yet, there's also a bit discouraging drawback to this approach to styling React components:
Do expect to face all the “standard” CSS problems: potential conflicts between definitions and mutual classes, attribute inheritance (both good and... bad)...
2. CSS Modules
And before we delve into the:
“why” you might rate using CSS modules as “the best way to style React components”
“how” to leverage their styling capabilities
... let us try to define them:
They're CSS files where all animation and all class names get automatically scoped.
Moroever, CSS modules help you “keep things clean” when it comes to all the previously mentioned problems that CSS stylesheets can challenge you with.
They make the most efficient approach to styling React components when you're dealing with complex applications.
And now, here are the steps to take for styling your reusable components using CSS modules:
import CSS file: import styles './DashedBox.css'
next, access className as you access to the object
And here you have 2 options at hand:
:local(.className) if/when you opt for create-react-app due to webpack configurations
.className in case it's your own React boilerplate that you're using
“OK, but how do I make my CSS modules work with Webpack now?”
A legitimate question that you might be asking yourself right now.
Here's how:
you simply include the modules early mentioned
next add the loader here below to your webpack.config.js file:
. . .
{
test: /\.css$/,
loader: 'style!css-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]'
}
. . .
3. Styled Components: Is This the Best Way to Style React Components?
“It is if working with class names to compose stylesheets is not really... your thing.”
Take it as a more “non-traditional” way of styling components, where you:
Create encapsulated styles and integrate them with the props of your components. In other words: instead of using className, you'd be using style attribute.
And styled-components — a JavaScript and CSS “combo — are no more than a library enabling you to use component-level styles within your React app.
Or, you can also see them as a “wrapper component”: mapped to HTML tags in order to style itself and its child elements.
This way, you can easily write regular CSS in your JS file.
The main advantages?
you get to store all the styling within the component
… to have separate and reusable UI for your React stateful/stateless components
… to build “isolated” components
And now, let me take you through all the steps required for leveraging this library's styling capabilities:
fist, just install the library itself: npm install styled-components –save
next, set up a variable by selecting a specific HTML element, to store your style keys const Div = styled.htmlElemnet`color: pink`
and finally, use that variable's name as a wrapper <Div></Div> type of React component
4. Inline Styling
This might just be the best way to style React components for you if it's only a few style properties that you need to add.
Don't expect for inline styles to be specified as a string in React:
They're not! Instead, they're mentioned with an object:
whose key is the style name's camelCased version
whose value is usually a string, the style's own value, actually
And you have 2 options at hand for “triggering” the styling capabilities with this approach:
you create a variable storing style property and get it sent through to the element like style={nameOfvariable}
you pass the styling — style={{color: 'pink'}} — directly
Still, don't get overly “enthusiastic” about using this approach to styling! At least not until you've taken note of all the challenges that it presents, as well (and there are quite a few):
you won't be able to use pseudo-classes, one of the core features of CSS (:active, :hover, :focus etc.)
expect duplication in markup each time you'll use a specific component: you won't be having your styles in your JS only, meaning that doing server-side rendering will lead to duplication, to using repetitive rules and the same style code for multiple components
you won't get any media queries: you're left with the solution of using a JS approach for “juggling with” different screen variations
and you can't use vendor prefixes, nor override a rule on the very same selector
In a few words: using inline styling might just not be the best way to style React components if:
... It's a UI-heavy, complex application that you're working on and this is due to the approach's highly restrictive usage.
Nevertheless, if you still consider that this option suits your preferences and your app's feature needs best, go for it! You could always use a library such as React JSS, Readium, React style to deal with the above-mentioned inline styling limitations.
The END! These are 4 most widely-used ways of styling components in React, along with their key benefits and their most discouraging drawbacks.
Which one would you rate as “the best way to style React components” according to your personal preferences and to your current app's “needs” in terms of styling capabilities?
Adrian Ababei / Jun 14'2018
There's no way around it, not anymore: with Google's index now mobile-first, adopting a mobile-first approach when building a new Drupal site (or redesigning a legacy one) is… a must! It no longer depends on a specific project's needs or on the used technology. The need to develop a mobile-first content strategy has gone from particular to universal.
And facing the challenge of:
(re)creating
optimizing
structuring
… content on your Drupal website means conforming to those specific patterns that mobile users have developed for reading content on their smartphones.
In short: developing a fully responsive Drupal site comes down to centering your mobile content strategy around the idea that:
It's for the smallest screen sizes that you should plan your content for, first things first … then scale it up from there.
Now, let's see precisely what it takes to develop a mobile-first content strategy. What focus points and must-have components to include:
1. Take the Smallest Screen Size as the Starting Point
In other words: think mobile-first!
And by “mobile” I do mean “smartphones” — the smaller the screen size, the better.
This way, you'll be adjusting your content so that it makes the most of the smallest interface. Starting “small” is the best way to stick to the “keep it simple” approach:
Thinking through every content-related decision in the light of the viewport size challenge will constrain you to keep the truly essential content elements only.
Hence, this “spartan” way of eliminating the unnecessary will reflect on your site's desktop design, as well:
It will turn out cleaner and lighter.
2. Use Visual Content Wisely: Weigh Your Choices of Images
The golden rule when it comes to the imagery that you'll use on your responsive website is:
If an image doesn't enhance and complement your content, then you're better off without it!
And I know what you must be thinking:
“But people remember what they see far more easily than what they read.”
True, you need to keep in mind that visuals do come at a cost, though:
Those stunning, visually-arresting images on your website risk to divert your users' attention from the message itself.
And still, probably the most heavy-weighing reason why you should use images wisely when you develop a mobile-first content strategy is: weigh.
Visuals risk to take up valuable screen space and thus:
outshine your calls to action themselves
impact your site's overall performance (leading to frustration)
Now that doesn't mean that you should strip your content off ALL the visuals! Absolutely not!
Just to be cautious and weigh your every choice, think through your every decision involving the usage of an image.
Once you've selected the truly essential ones, keep in mind:
not to no resize them (or optimize them in any other way) before uploading them to your CMS: let Drupal do the heavy-lifting here
to leverage the Responsive Image module's (Drupal 8) capabilities for resizing them to fit the given screen sizes
3. Content Before Design
This is the right sequence to follow when you're designing (or re-designing) your Drupal site with mobile users in mind:
First, you create and strategically organize your content and upload it to your Drupal 8 CMS. It's only then that you focus on styling and developing a responsive and visually-striking web design.
If it's legacy content that you're dealing with, trying to convert it to mobile, the very first step to take when you develop a mobile-first content strategy is:
Removing all the design elements from your written content.
4. Create a Hierarchy of Your Calls to Action
Making the most of a small interface means also setting your priorities in terms of calls to action:
Pair each one with a corresponding objective, evaluate them all wisely, then select THE call to action that's most critical for you and place it — and it alone — above the fold.
5. Organize and Optimize Your Content for Mobile Devices
I'll briefly list all the key requirements that mobile-friendly content should meet — aspects to pay attention to when writing content for mobile devices — for I'm sure they're nothing new to you:
the phrases should be kept short and concise, thus eliminating the burden of “never-ending-scrolling”
the content should be sharp, targeted and skimmable, so users can easily “digest” it and modular, so that users can swiftly browse through it
“modular” meaning made either of multiple clear paragraphs — each one standing for one thought — or chunks of 3 paragraphs at most
6. Optimize Media, too, When You Develop a Mobile-First Content Strategy
And there are a couple of essential steps that you mustn't overlook when it comes to mobile-optimizing your media:
always go for thumbnails instead of video players that your users would have to load and thus strain on your site's valuable resources
don't ever use autoplay on your audio and video content
optimize your sound, image and video files both for large and small devices
7. Trim Down Your Navigation Menu
In other words: when you develop a mobile-first content strategy, consider simplifying your navigation to its truly essential links.
No user would gladly scan through a “beefy” navigation menu taking his device's entire screen:
flatten your navigation: stay away from the technique of piling up submenus, layers and navigation points
feel free to place the links that you'll remove on other places on your website (or even to turn them into calls to action)
8. Convert Your Legacy Content to Mobile-Friendly Content
If it's a legacy Drupal website that you need to restructure and to adapt to your mobile users' specific patterns for browsing through and consuming content on their smartphones, then it's time you:
dug into your static HTML
… and cleaned it up
And by “cleaning it up” I do mean:
removing inline media
removing the fixed-width tables
eliminating floats with content
breaking it down into skimmable chunks of content
… that can be easily structured into content fields.
The END! These are the 8 main aspects to focus on when you develop a mobile-first content strategy.
Now time to test the “saying” that:
“Creativity strives under constraints.”
… and to make the most of those small interfaces.
Adriana Cacoveanu / Jun 11'2018
“Learn from your mistakes” should be every developer's life mantra. But that doesn't mean that they should be all your mistakes, right? With a list including the most common Angular mistakes at hand, you'd get to narrow down the number of possible pitfalls that you risk falling into to the... uncommon, the less predictable ones.
So, what are the traps that Angular developers fall into most often as they build their applications?
We've run our own "investigations" for you:
gone through the code examples on the web
ran an inventory of the most frequent questions on StackOverflow
looked over some of the issues that we've knocked our heads against while working on our own Angular projects
… and trimmed down our list to 5 most frequent mistakes that Angular developers make:
1. ngOnChanges vs ngDoCheck: Misunderstanding When the ngDoCheck Gets Triggered
"I have used OnPush strategy for my component and no bindings have changed, but the ngDoChecklifecycle hook is still triggered. Is the strategy not working?"
I bet that you've stumbled across this question (maybe put into different words) on various developer forums. It could easily win any “popularity” test there since it keeps coming up again and again.
But, before we give it a straight answer and settle this matter for good, let's focus on these 2 “change detecting” lifecycle hooks in Angular. And see where the problem stems from:
As you well know it, AngularJs has the watch feature, which “alerts” you whenever a value changes. Angular, on the other hand, has replaced the watch and scop feature with component inputs as properties. Moreover, it has added the ngOnChanges lifecycle hook, as well.
And here's where things get “tricky” and risk to turn into the trap that many Angular developers fall into:
The OnChanges event doesn't emit if/when a deep field of the input property changes. Hence, the value of the input is the reference of the object.
How do you approach this problem? You have several methods at hand, in fact, but I'm going to focus on the most common one:
Using the ngDoCheck lifecycle hook once you run the change detection process!
Now here's the answer that I've promised, to the above-mentioned common developer question:
The onPush strategy for detecting changes in Angular does work: the hook is triggered by the design itself!
Note: another ridiculously frequent mistake that developers make is to take "Angular" for "AngularJS"! Be better than that: the term "AngularJS" should be used only when you refer to the old Angular and to Angular 1, while Angular 2/2+ 4 and 5 is just... "Angular". Mind you don't delve deep into this confusion yourself, too!
2. Forgetting to Unsubscribe: One of the Most Common Angular Mistakes
“Forgetting” or simply ignoring this issue.
And you have no “excuse”, you know, for overlooking to clean up your subscriptions in Angular. Considering that there are methods and libraries developed precisely for handling these unsubscriptions once you've finished using an event or an observable in JavaScript.
Why does this “clumsiness” risk to grow into a major issue? Because lingering subscriptions cause memory leaks in your system.
And when it comes to the unsubscription process, there are 2 scenarios:
you trigger the OnDestroy lifecycle hook if it's in a component that you've subscribed in
you initiate the lifecycle hook yourself if it's a service that you've subscribed in (since, in this case, there's no available hook for you to fire)
To recap: Remember to unsubscribe when you no longer use a service/component!
3. The Wrong Use of Providers
One of Angular's (compared to AngularJS) key improvements is its Hierarchical Dependency Injection, agree?
This means that now you're free to instantiate a service several times (services used to be singletons back in the AngularJS's “glory days”, remember?).
Now that being said, let's have a look at a more than likely scenario:
Imagine yourself fetching your heroes using a heroes service:
@Injectable()
export class HeroesService {
heroes: Hero[] = [];
constructor(private http: Http) {
this.http.get('http://give-me-heroes.com').map(res => {
return res.json();
}).subscribe((heroes: Hero[]) => {
this.heroes = heroes;
});
}
getHeroes() {
return this.heroes;
}
}
Nothing unexpectedly wrong till here:
the data is being fetched in the constructor
there's also a getHeroes method for retrieving the heroes
Now, let's take a look at the hero component, too:
@Component({
selector: 'hero',
template: '...',
providers: [HeroesService]
})
export class HeroComponent {
constructor(private heroesService: HeroesService) {}
}
@NgModule({
declarations: [HeroComponent]
}
export class HeroesModule { ... }
As you can see, first the HeroComponent declares the HeroesService provider in the @Component.providers array, next it incorporates it in the constructor.
All well and good till you realize that each HeroComponent instance instantiates a new instance of the HeroesService.
To put it more simply:
Your HeroesService will be fetching the data (by HTTP request) several times, for each and every HeroComponent instance!
And this is due to the Hierarchical DI in Angular.
The solution for avoiding this issue — no doubt one of the most common Angular mistakes?
Declaring the service in the @NgModule.providers instead:
@Component({
selector: 'hero',
template: '...'
})
export class HeroComponent {
constructor(private heroesService: HeroesService) {}
}
@NgModule({
declarations: [HeroComponent],
providers: [HeroesService]
}
export class HeroesModule { ... }
There! The provider will now be instantiated once and for all. “For all” the HeroComponent instances I mean.
“How come?” You might ask yourself.
Because the provider (declared in the NGModule now) is a singleton now. Therefore all the other modules can use it.
4. Manipulating the DOM Directly
Although I've already said this about another mistake from this list, I now tend to consider this one here instead as being one of the most common Angular mistakes:
Manipulating the DOM directly; oftentimes from the controller itself!
And this is one of those top 10 Angular mistakes that any developer stands a high risk of making. Since manipulating the DOM is such a common task when using this platform:
you might need to render SVG
you might need to refresh a page's title based on a context change
you might need to set the focus on a control after a validation error
… and the list of possible situations goes on
Then... you fall right into it: you take the easy way out and hack the DOM directly!
Now what I feel like pointing out it here is that:
Angular's grown from a web framework into a platform!
And this can only mean that you're now free to decouple your Angular application's codebase from the renderer and:
have your app executed in on the server
… in the browser
… as a native app
And decoupling opens the door to other possibilities for you to explore and to tap into, such as using web workers or AOT (ahead of time compilation).
Speaking of the latter:
AOT enables you to compile your app's templates in the build time of your server. Moreover, you won't need to use the oversized @angular/compiler package in your bundle, which leads to a lower size and load time.
Yet, for future-proofing these “facilities” that Angular provides, you'll need to abide by... some sort of rules at least. And one of them is:
Restraining yourself from manipulating the DOM directly, using jQuery, the global document object or the ElementRef.nativeElement.
Instead, use the Renderer2 service (or Renderer for Angular 2):
It's 2 things that this wrapper to the view mutation layer will enable:
for the default layer to be used in the browser
for the renderer to get replaced with a more suitable one whenever your Agular app runs on another platform (e.g. a phone)
In short: Resist “temptation” and never ever touch the DOM directly!
5. Declaring The Same Component in More than Just One NgModule
And declaring a component in multiple NGModule-s is one of those most common Angular mistakes that end up throwing an error “at” you.
“Why, so?”
Because you need to declare each component in its own NgModule — and to list it in the @Ngmodule.declarations array — in order for it to be available for the views.
If you do need to declare the very same component in multiple modules, you'll need to consider the relationship between those modules:
Is it a parent-child one, maybe?
If this is the case, then:
use the child's NGModule.declaration to declare the HeroComponent in the child module
use the chid's NGModule.exports array to... export the HeroComponent
use the parent's NGModule.imports array to import the child module
If not (if we can't be talking about a parent-child module relationship), then you'll need to declare another NgModule as the module of the shared data.
Final Word
It's only by knocking your head against unexpected issues while building your projects on this platform, that you'll get to grow as an Angular developer.
And still, instead of embracing the “fail fast, fail often” concept, wouldn't it be best if you:
learned from other developers' mistakes, thus knowing what the most common Angular mistakes are
ensured that you failed "rarely" instead?
RADU SIMILEANU / Jun 05'2018
Building a web app using React for the first time? Then it must be a simple "Hello World" type of app that you're planning to set up. One that would guarantee you a smooth first-hand experience with React.js...
So, you're wondering:
"What's the fastest way to build a basic app in React?"
A question then followed by a... myriad of other questions:
"What dependencies should I use?"
"What React stack should I go for if it's just a simple web app that I want to create?"
Now it's about time that you moved from questioning yourself to code writing, don't you think? Here's a simple and easy-to-follow tutorial on how to create a React app from scratch.
1. Create a New React Project Folder
The very first step to take is to start a new React project. Obviously!
Note: Make sure you have NPM and Node installed in your environment first things first!
For this, just run the command here below:
npm install -g create-react-app
Tada! Your React boilerplate app creator has just bee installed!
Now the second code that you'll run is going to create your "Hello World" React app itself:
create-react-app hello-world
Running an imaginary magnifying glass across your app's structure you can't help not noticing the 3 major file types there:
public/index.html files
src/index.js files
src/App.js files
And scanning your app's backbone a little deeper you'll spot:
a div with the id root
this piece code here below in the index.js.file:
ReactDOM.render(, document.getElementById(‘root’));
If we were to translate this code segment into plain language it would go something like this:
React injects your app component into the div by using the root id.
2. Write the Simplest React Component
"But what is an app component more precisely?"
Take it as React's convention to use the same names both for JavaScript files and the component.
And now the code for your more-than-basic component would look something like this:
import React, { Component } from 'react';
class App extends Component {
render() {
return (
<div className="greeting">
<h1> Hello World! </h1>
</div>
);
}
}
Feel free to create a JavaScript class for it and to extend it from the Component class.
Next, implement the render () method, which will return a whole suite of elements (unlike prior to React 16, when one had to return a single element per each render method that was being implemented).
Then, running the npm start command in your app's directory, you'll see the "Hello World" text message displayed at http://localhost:3000.
Hello World!
3. Building a Web App Using React and JSX
And I feel that I should start by defining JSX, right? Before I go ahead and delve into details on how to use it with React:
An extension to the JavaScript language — therefore a template language — with a structure similar to HTML. One that makes a great team with React.
Its true "power" is that it... empowers you to write your HTML components and React components in an HTML-like tag:
<HelloWorld />
And here's JSX "in action", right in this "Hello World" app that we're building here:
The following code:
const element =
(
<h1 className="greeting">
Hello, world!
</h1>
);
... gets compiled to the familiar JavaScript code here below:
const element = React.createElement(
'h1',
{className: 'greeting'},
'Hello, world!'
);
See? A familiar HTML-tag language that makes structuring an app's code a whole lot easier for any developer!
And this is JSX's main role and the very reason why it works perfectly with React.
4. How to Use State vs Props in React.js
How about creating another component as we're building a web app using React?
Let's name it "Mary":
import React, { Component } from 'react';
class Mary extends Component {
render() {
return (
<div>
<h2> Hi, I am Mary </h2>
</div>
);
}
}
export default Mary;
Bravo! Next, we can include it, as a child component, into our existing React App component:
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
render() {
return (
<div className="greeting">
<h1> Hello World! </h1>
<Mary/>
</div>
);
}
}
export default App;
Note: Noticed the import statement for our "Mary" component? It plays a key role since without it our React app wouldn't work. And this because React wouldn't be able to identify, all by itself, the component that corresponds to the Mary tag.
Curious now how you could manipulate your "Mary" component? How you can control its behavior?
By manipulating its... state object, that's how!
Note: each React component comes with its own state object.
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
constructor() {
super();
this.state = {
greeting: "Hello World!"
}
}
render() {
return (
<div className="greeting">
<h1> {this.state.greeting} </h1>
<Mary/>
</div>
);
}
}
export default App;
See the "greetings" property — having the "Hello World" value — that corresponds to the state object? Remember that you're free to add as many properties as needed.
Next, how about trying to pass data from our App component into its child one, Mary:
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
constructor() {
super();
this.state = {
greeting: "Hello World!",
parentMessage: "Hello Mary!"
}
}
render() {
return (
<div className="greeting">
<h1> {this.state.greeting} </h1>
<Mary newMsg={this.state.parentMessage} />
</div>
);
}
}
export default App;
Noticed the "newMsg" key there? It's precisely this key that's responsible with the data transfer.
Now, as for the child component "Mary":
import React, { Component } from 'react';
class Mary extends Component {
constructor(props) {
super(props)
this.state = {
greeting: props.newMsg
}
}
render() {
return (
<div>
<h2> {this.state.greeting} </h2>
</div>
);
}
}
export default Mary;
If you're willing to give this piece of code a deep scan, you'll notice that there's a "props" method argument in there.
Keep in mind that it's precisely this object that stores all the data transferred from the parent component to the child React component.
Also, another "detail" that you should be able to detect is the "newMsg" property (transferred from the parent/App component); we've used it to initialize the state of the Mary component.
5. How to Use The React (Component) Lifecycle Hooks
I won't get into too many details, since React's documentation is already more than "enlightening" when it comes to:
the different lifecycle methods (or hooks) to be invoked for each state of a React component
the precise times in the development process for triggering each hook
Nevertheless, I'll briefly add that all these methods to be used across your React components' lifecycles fall into 3 main categories:
mounting hooks: use them at the very start, when your React component is being rendered in the browser page
updating hooks: fire them when your component gets re-rendered on the web page. And this happens if/when changes are made to the state/props objects
unmounting hook: invoke the componentWillUnmount() hook shortly after your component gets removed from the DOM
Note: Since React 16, the collection of hooks has enriched with a brand new one: componentDidCatch()! Fire it whenever you're dealing with an exception during the other lifecycle methods of your component.
In other words: invoke it whenever a component fails to function as it should when you're building a web app using React!
As for the specific way that React manipulates DOM via the Virtual DOM that it creates, feel free to have a look at our post precisely on this topic: How React Virtual DOM Works!
The END!
Your turn now: go through all the steps included here and, step by step, set up your first basic React application!
RADU SIMILEANU / May 31'2018
Content is a way too valuable asset not to handle it with utmost care — from its creation to its revision, all the way to its... distribution. And with utmost efficiency, as well! But how do you choose the business software to “orchestrate” your entire content workflow? Since, on one hand, you have the top enterprise content management systems in 2018 and, on the other hand, you have... Drupal?
And the dilemma that you're facing right now could be summed up like this:
Choosing between a complex ECM system with a load of powerful tools that comes at a cost and a feature-rich one — already famed for its robustness and customization options — with no price tag on...
Now to ease your decision-making process, let's compare these enterprise information management solutions, the top rated ones, to Drupal, by weighing their feature loads and costs.
1. But What Is an Enterprise Content Management System More Precisely?
First, let's try to define what we mean by “content” in relation to a content management software:
Content is all the written pieces of information entering and “moving about” your organization. It comes in the form of:
internal process documents
content for your company website (or blog)
sales-focused content
targeted, custom content available to paying cutomers only
... and the list goes on.
As you can see, I've intentionally left out graphical and audio-visual content. And this because it's only text-based digital content that a CMS would handle.
Now, coming back to our initial question:
An enterprise content management system is a software geared at managing all the processes in your content's lyfecycle: creation, revision, publication, distribution to multiple channels, promotion etc.
Packed with different sets of tools designed to automate all your content-based processes, an ECM system is a... “Swiss knife” type of business software.
The one you'd use to streamline your content workflow(s).
2. M-Files, One of the Top Enterprise Content Management Systems in 2018
Introducing the enterprise-leveled information management solution of the year: M-files!
The promise that it makes?
To break the “siloed information” pattern and enable users to access specific content from any buiness system, any device.
… to easily access it, but also to organize it, to manage it, to identify particular information/documents, to set up custom workflows and even to manage document reviews.
Top features
version control
automated workflows
pre-built search engine: you get to track documents by type, name, keywords; it provides within-text search features as well
notifications: users get alerted whenever they'll need to review or approve changes made to documents
approval processing
permission management and offline access
integration capabilities: it easily integrates with Microsoft Dynamics, NetSuite, SAP, Salesforce
document collaboration tools: co-authoring features and check-in/check-out tools
Price
Mi-files is one of those enterprise content management vendors that leverage the quote-based method for pricing their services.
Basically, there are no standard prices, as there are no standard packages that they offer, only tailored content management solutions.
Cons
The great majority of negative user feedbacks revolve around the M-Files mobile app's limited functionality.
2. OnBase
Another one of the top enterprise content management systems in 2018 is OnBase:
An all-in-one software coming “equipped” with:
business process management tools
integrated document management tools
records management tools
And before I “expose” to you its most heavy-weighing features, I feel that I should put the spotlight on its versatility feature first:
You get to easily configure your OnBase ECM system to fit any environment of choice.
Top Features
approval process control
indexing
version control
built-in search engine
document management
Cons
Do expect a steep learning curve! So, be prepared to invest a significant amount of time in growing comfortable with using it.
In learning to “juggle” with all its apps and functionalities.
Price
You'll need to contact the OnBase team for a custom pricing plan.
3. Box
Box is a cloud content management platform built to assist you with:
online sharing your files
storing your files
integrating content across your entire “infrastructure” of digital tools via open APIs
collaborating within your team
Top Features
granular access permission
easy integration with other platforms
advanced security capabilities: device trust, watermarking, data governance
easy integration with other platforms
collaboration tools: a document management system that enhances collaboration among end-users on various file types and devices; tools which also enable them to choose the right storage place, to set up metadata-driven content workflows etc.
Cons
Even top enterprise content management systems manage to collect their own “pile” of “bad reviews”. What users reproach OnBase here, for instance, is its user-based pricing model.
In other words, if you have +100 people in your company, expect to get charged separately for each email domain... and thus to overstretch your budget over time.
Price
Box pricing plans start from €4.50 per user/month (we're talking about a starter business plan here) and can go up to $500 per month or more if it's a “build with BOX platform” plan that you'll select.
4. Drupal
And now that we've put the top-rated ECM systems in 2018 into the spotlight, let's see what Drupal here has to offer. How it can counterbalance all these heavy loads of tools, features, and functionalities.
Drupal's Key Features
advanced integration capabilities: Drupal “spoils” its end-users with conveniently accessible API, backed by a rich collection of modules built precisely for 3rd party integrations
no maintenance effort required: since it runs in Acquia Enterprise cloud, Drupal gets automatically updated; maintenance is already included in the Enterprise support costs plan
feature richness: and we're talking here about features, plug-ins (thousands of them) and content management tools that you get right out of the box
modular architecture: which goes hand in hand with the unlimited freedom of customization that you'll get to leverage
high performance: Drupal's already famed for its robustness and capabilities to withstand high influxes of traffic
unmatched scalability
a full toolbox (contributed modules here included) put at editors' disposal: Drupal's also won its reputation as a CMS that's been constantly improved to enrich the experience; all the in-built content-handling tools speak best of its “empower the content creator/end-user” philosophy
Price
license costs: unlike the top enterprise content management systems previously outlined, Drupal's open source; there are no license costs, only support costs associated with the Acquia Enterprise Platform
vendor lock-in: all modules and plug-ins that you might select and mix and match to custom-tune your CMS are free
development costs: Drupal resources are available to anyone who wants to build and then to custom tune and scale up its CMS
In conclusion...
… Drupal comes feature-packed and, moreover, it “spoils” you with unlimited freedom of customization. And all this without putting a price tag on.
On the other hand, some of the top enterprise content management systems do tempt you with their feature richness, but at a cost. One that can go up precisely if you feel like customizing your ECM solution or scaling it up sometime in the future.
In short: you do get your share of customization freedom... but not for free.
So, it's not really an “apples vs oranges” type of dilemma that you're facing, but rather an:
Apples vs Apples with a price tag on
Adriana Cacoveanu / May 29'2018
About to build your very first Angular app? Then you must be planning to create an Angular project with Angular CLI, right? The much-acclaimed tool that the Angular team built precisely to jumpstart the whole development process.
… to have a simple app scaffolded, generated and deployed in no time, by entering just a few commands (so they say, at least).
And since I'm sure that you don't want to waste these bundles of convenience by letting yourself tangled up in overly complex explanations instead, I've kept things simple with this guide.
So, here's how you create and run your first Angular project via the Angular command-line interface:
1. But How Precisely Can Angular CLI Jumpstart Your App's Development Process?
Take this command-line interface as a starter kit “present” that the Angular team has nicely wrapped for you:
it's practically geared at empowering you to get up and start developing a new Angular app in no time
it takes just one short command to generate a default Angular project that would include all the needed dependencies (in the node_modules folder), as well as testing files for each component
Now, this is what I call a major kickstart! It's got you covered from the stage of setting everything up, to creating the Angular project itself, to testing it and finally deploying it.
Other key usages of the Angular CLI that we're not going to focus on in this tutorial here are:
real-time server maintenance and support
building applications for production
adding new features to your existing app
running tests on your application units
2. Setting It Up: Install Angular CLI Globally
Before you jump to the part where you create an Angular app using Angular CLI, you need to install the command-line interface itself. Globally!
And this is the “power” command to enter in your terminal with the npm installed:
npm install -g @angular/cli
Notes:
if you already have the CLI installed, make sure it's the latest version
if you need to update it, these are the commands to enter:
npm uninstall -g angular-cli
npm uninstall --save-dev angular-cli
And there's more! A few more must-have dependencies that you need to make sure that are already installed and upgraded to their latest versions:
Node.js: v6.9.x +
npm: 3.x.x +
3. Create an Angular Project With Angular CLI
With your command line interface ON, use it to enter THE one and only command that will generate a new Angular project for you. One incorporating, by default, all the needed dependencies:
ng new ng-yourproject
Tada! A “yourproject” named directory has just been generated. That's where your new Angular project — along with all the requested dependencies — gets stored.
Eager to test it out? Just run the following command in your terminal:
ng serve
Your Angular app will then get built and served up to localhost:4200. Feel free to open this URL in your browser and it's the here-below screen that you should be able to see:
Basically, it's the default application shell itself rendered by the CLI.
4. “Deconstructing” Your New Angular Project: What Does It Include?
Now, before you go ahead and do your “tweaking” on your newly created app, let's see what you've got in there! What are the elements that the CLI has generated for you to help you jump to development right out of the box?
For this quick “scan”, open your Angular project in your IDE of choice and start “exploring” your src/folder:
src/*
styles.css
any styles that you'll plan to apply globally, it's this file that you can add them to; and it's here, as well, that you can import new .css files (Bootstrap or any other styling frameworks of your choice)
index.html
where your Angular app gets started
src/app/*
app.component.ts
this is where your app's one and only (for now at least) component gets stored
app.module.ts
the modules Angular needs for managing your app's components
note: @NgModule marks the class file as a module and this is what makes it similar to @Component
5. Create a New Component
Remember your “one and only component” that I mentioned during the previous “inventory” of all the “bunch of stuff” that CLI has generated in your project?
Well, how about creating a new one now? One that would load under that root component?
Just run the following command to generate it:
ng generate component the-quote
Next, time to “show it off” in your browser:
<h3>{{myQuote.quote}}</h3>
<small>- {{myQuote.by}}</small>
Add the app-the-quote selector to the root component that the CLI generated in your Angular project:
<h1>
{{title}}
</h1>
<app-the-quote></app-the-quote>
6. Apply External Styling
Now you do agree that when you create an Angular project with Angular CLI applying styling is a key step.
So, let's add your favorite CSS framework to your new application!
Me, it's Bulma that I'll be using in this tutorial here:
npm install bulma --save
With our CSS framework installed, we'll need to enable it to load the CSS file into our Angular app. For this, just place the relative path within the .angular-cli.json file., to the file in the styles array more precisely.
...
"styles": [
"../node_modules/bulma/css/bulma.css",
"styles.css"
],
...
“Tempted” to display some icons now, as well? Then go ahead and add the font-awesome library as cdn link.
For this, just include the stylesheet right into your index.html:
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
Et voila! This is how you create an Angular project with Angular CLI!
What do you think? Is the Angular command-line interface an extremely useful tool to jumpstart your project with or did you expected your “starter kit” to include, right out-of-the-box, more elements to get you started?
RADU SIMILEANU / May 25'2018