Editor’s Note: This is the second in a five-part series on refactoring and modernizing PHP applications. If you were to identify the most expensive part of any development project, what would that part be? The planning phase? Acquiring copyright or intellectual property? Marketing and advertising? All of these would be wrong. The most expensive part […]
The post Part 2: Code Is The Most Expensive Solution appeared first on BrandonSavage.net.
Latest PECL Releases:
Volt::convertEncoding to no longer using iconv for a fallback since it causes issues with macOS #14912
PhalconDbDialectMysql - unquote numerical defaults #14888, #14974
FALSE to Enum::DENY #14974
PhalconHttpResponse::__construct checks content data type. Now a TypeError will be thrown if incompatible data type was passed #14983
PhalconFlashFlashInterface's methods: error, message, notice, success and warning #14994
PhalconMvcModelInterface::sum #15000
PhalconMvcModelCriteria::getLimit so that integer, NULL or array will be returned #15004
PhalconMvcModelManager::getCustomEventsManager to return NULL instead of boolean FALSE if there is no special events manager #15008
PhalconMvcModelMetaData::getDI so that now it will throw a PhalconMvcModelException if there is no DiInterface instance #15011
PhalconHttpRequest::getJsonRawBody to use json_decode instead of PhalconJson::decode #14936
PhalconFactoryAbstractFactory to expose getService which will throw an exception if it does not exist. Removed checkService and adjusted all references in newInstance() calls. #15038
PhalconHttpMessageResponse, PhalconHttpMessageServerRequest and PhalconHttpMessageUri to work with clone. #15040
PhalconMvcModelQueryBuilder::getPhql to add single quote between string value on a simple condition #14874
{{ ... }}) #14476
Tag::friendlyTitle to correctly convert titles under MacOS and Windows #14866
cache fragments and thus searching for the viewCache service (deprecated for v4) #14907
IN operator precedence in Volt #14816
PhalconAclAbstractAdapter's methods: getActiveAccess, getActiveRole and getActiveComponent #14974
PhalconAnnotationsAnnotation's properties: $arguments and $exprArguments #14977
PhalconAnnotationsAnnotation's methods: getArgument, getName and getNamedArgument #14977
PhalconHttpResponseCookies::setSignKey #14982
PhalconConfigConfigFactory::load and PhalconConfigConfigFactory::newInstance to explicitly indicate the return type as PhalconConfig instance #14978
PhalconDispatcherAbstractDispatcher::dispatch
PhalconDispatcherDispatcherInterface::dispatch
PhalconFilter::get
PhalconHttpMessageAbstractCommon::cloneInstance
PhalconHttpMessageAbstractCommon::processWith
PhalconHttpMessageAbstractMessage::withAddedHeader
PhalconHttpMessageAbstractMessage::withBody
PhalconHttpMessageAbstractMessage::withHeader
PhalconHttpMessageAbstractMessage::withProtocolVersion
PhalconHttpMessageAbstractMessage::withoutHeader
PhalconHttpMessageAbstractRequest::withMethod
PhalconHttpMessageAbstractRequest::withRequestTarget
PhalconHttpMessageAbstractRequest::withUri
PhalconMvcModelBinder::findBoundModel
PhalconValidation::getEntity
PhalconValidationValidationInterface::getEntity
PhalconCrypt::$key to satisfy the interface #14989
PhalconDi::getInternalEventsManager #14992
PhalconFlashAbstractFlash's methods: error, notice, success and warning #14994
PhalconTranslateInterpolatorFactory::newInstance #14996
PhalconMvcModel::sum #15000
PhalconMvcModelCriteriaInterface::getLimit and PhalconMvcModelCriteria::getLimit to follow documentation and original purpose #15004
PhalconMvcModel::count and PhalconMvcModelInterface::count to reflect original behavior #15006
PhalconMvcModel::getEventsManager to reflect original behavior #15008
PhalconMvcModel::average and PhalconMvcModelInterface::average to reflect original behavior #15013
PhalconMvcModelMetaData::getColumnMap and PhalconMvcModelMetaData::getReverseColumnMap to reflect original behavior #15015
PhalconMvcModelMetaDataInterface::getColumnMap and PhalconMvcModelMetaDataInterface::getReverseColumnMap to reflect original behavior #15015
PhalconMvcModelCriteriaInterface::getColumns and PhalconMvcModelCriteria::getColumns to reflect original behavior #15017
PhalconDbColumn::getSize and PhalconDbColumnInterface::getSize to reflect original behavior #15019
PhalconDbColumn::getAfterPosition and PhalconDbColumnInterface::getAfterPosition to reflect original behavior #15021
PhalconMvcModelManager::executeQuery and PhalconMvcModelManager::ManagerInterface to reflect original behavior #15024
PhalconMvcModelResultset::getFirst and PhalconMvcModelResultsetInterface::getFirst to reflect original behavior #15027
PhalconMvcModelQuery::_prepareSelect to properly prepare a SQL SELECT statement from a PHQL one #14657
SerializerInterface usage for PhalconMvcModelResultsetComplex::unserialize as well as PhalconMvcModelResultsetComplex::unserialize #14942
PhalconTranslateInterpolatorFactory::$mapper as well as PhalconTranslateInterpolatorFactory::$services in favor of PhalconFactoryAbstractFactory ones #15036
The post Interview with Nicolas Grekas appeared first on Voices of the ElePHPant.
The post Interview with Nicolas Grekas appeared first on Voices of the ElePHPant.
All content management systems (CMS) have their own strengths and weaknesses. Some are meant for very niche offerings such as eCommerce or membership sites, while others are a jack-of-all-trades. In addition, these systems range from open source to proprietary.
Beyond the market-leading WordPress, I have had the opportunity to dabble in a few other systems. The experiences have been uneven.
I won’t pretend to have in-depth knowledge of every software package out there. But I have enough experience to understand what makes for a good system. It’s about ease of use and putting users in the best position to do things the right way.
For the most part, there’s been a ton of improvement over the past decade. Still, not everything is where it should be. With that in mind, here are five things that no CMS should be doing in modern times.
It’s hard not to notice that the web has a lot of standards and best practices these days. Markup has to be structured semantically and content needs to be accessible. In addition, CSS should be used for styling elements such as containers and typography.
Yet, I still see content editing UIs that facilitate, and thus promote, doing things the wrong way. For example, take a proprietary, membership-based CMS I’ve worked with. Its content editor still utilizes tables for multi-column layouts as well as old school HTML font tags. Um, 1999 called, they want their markup back!
Now, there’s a difference between slight deviations from standards and an outright disregard for them. The fact that any software would still use such outdated techniques (by nearly two decades) is kind of bewildering – not to mention irresponsible.
The average person who creates content places a great amount of trust in an editor UI. We need the software to turn our text and images into clean, accessible code. It doesn’t have to be perfect, but it should never hinder anyone’s ability to consume it.
For some of us, working at a cluttered desk is frustrating. It’s hard to be creative – or even concentrate – with various junk lying around. A CMS dashboard is much the same.
Dashboards should be both minimal and easily customized. The WordPress Dashboard starts off this way, but quickly becomes a heaping mess as you install more themes and plugins. Dashboard widgets can be turned off easily enough. But the many nagging notification messages shown throughout the back end aren’t so easy to jettison.
Part of the issue is that, as an open source system, WordPress doesn’t have much control over how these notifications are deployed. There have, however, been some efforts to wrangle notices in a more user-friendly way.
This is one area where some proprietary systems, especially those that don’t allow for third-party plugins, have an advantage. They can take complete control over the UI and decide what notifications are needed and how they will be displayed.
Then too is the need for distinguishing between legitimate system-related notices and cheesy upsells. It’s understandable that software developers need to make money. However, being bombarded with ads and forced to dismiss the same notification a hundred times crosses a line. There need to be strict guidelines regarding this type of behavior.
Just because your website was built using a particular CMS doesn’t mean it will forever stay in that system. You might eventually outgrow the platform you started out with or simply want to try something new. This is not always easy.
With some proprietary systems, the site you build either stays with the provider or it goes away altogether. Content and design can’t be natively exported for use elsewhere. In some instances, you can’t even export a copy of your site for internal staging purposes.
In that case, you’re left searching for a third-party tool to extract what you need. Fail that, you might be copying and pasting source code out of your web browser.
It’s reasonable that some functionality may not be exported – like, say, a shopping cart. But in this day and age, the content itself should at least be available to export as a CSV, JSON or XML file. Is that too much to ask?
All software evolves over time – that’s a given. Bugs are squashed, security holes are filled and new features are unveiled. And they are all rightly expected of a CMS.
However, there is also a great need for stability. When you deploy a website on your CMS of choice, you want to know that it will continue to work, version after version.
Big, sweeping changes can throw a monkey-wrench into the works. If all the “what-ifs” are not accounted for, any fundamental change to how a system works can have dire consequences. Specific features, or even an entire website, could break after the change is implemented.
New features are still important. They help to attract new users and ideally make life easier for existing ones. But they need to be carefully thought-out in order to minimize any negative impacts.
If an app gains a reputation for breaking websites, it’s not going to be around very long.
It seems like communication might be just as important as code. Because, while a system may have compelling features, users will need to know about them in order to take advantage.
Likewise, those behind the scenes at a CMS need to know what their users want and need. That information is key in deciding which features to implement and which bugs need fixed.
But communication is a big job. It encompasses areas like documentation, user support and building community. A lot of effort needs to be spent here, which is difficult even for industry giants. For smaller systems, it may stretch finite human resources to the max.
Still, it’s worth the effort. A failure to keep an open dialogue with users will erode relationships and may cause a mass exodus from the platform.
Ultimately, a CMS will be judged on whether it fulfills the needs of its users. None are perfect in this area, but some are far ahead of others.
The best systems allow us to create content in an accessible manner. They’ll develop features that maintain stability and will provide at least some backward compatibility. In addition, these systems will respect a user’s right to their own content and facilitate portability.
Above all, a good CMS will keep an open line of communication with users. The open dialogue will benefit everyone and help to ensure a bright and productive future.
On the other hand, systems that fail in these areas will most likely cease to exist over the long term.
The post 5 Things a Modern CMS Shouldn’t Do appeared first on Speckyboy Design Magazine.
Emoji seems to have invaded every part of our culture. What started out as a niche feature for mobile phone users and computer geeks has become its own phenomenon. Now, we see these little characters on t-shirts, marketing campaigns and even not-so-funny feature films.
It wouldn’t be a stretch to say that emoji have become a sort-of common language. Whether you speak English, Japanese or Swahili, certain characters are just universally recognized. As such, they can break down barriers in their own, cute way.
Naturally, the web design community utilizes and experiments with emoji quite a bit. Today, we’d like to showcase some of the more interesting and fun examples from CodePen. They run the gamut from simple CSS recreations, to clever animation that brings these little guys and gals to life. Enjoy 😊
This JavaScript-based animation is interesting enough on its own. But it’s also interactive. Moving your cursor over a face removes it from the screen, sort of like popping bubbles. Clicking on the canvas restarts the entire process.
See the Pen
gap – pure JavaScript by Toshiya Marukubo
Because emoji is so universal, it makes for a great learning tool. This interactive demonstration of CSS pseudoclasses benefits from the use of helpful “pseudocats”.
See the Pen
Structural pseudocats 🐱 by wendko
Developers are continually getting better at creating images via CSS. Here, we have a surprised-face emoji that is crisp, clean and scalable. It’s also been written with surprisingly little code.
See the Pen
Surprise face by Alexander Vega
One of the more popular usage of emoji is in games. They make for great, easily-recognized characters while also adding fun to the mix. This particular game is similar to a slot machine. Click the “spin” button and see which cute animal you land on.
See the Pen
Emoji Spinner by Melvin Idema
What’s not to love about this emoji bear? It’s clearly a fun-loving animal, with sunglasses and backwards cap. It apparently writes code as well, judging from the super-cool scrolling animation in those lenses.
See the Pen
Shades Loader 🐻 by Jhey
Happy or not, emoji does reflect what’s happening in our society. As such, it’s no surprise that this COVID-19-inspired character has been developed. The disgruntled little virus bounces pensively, apparently wary of an inevitable cure.
See the Pen
Corona Virus SVG (Covid-19) by Sourav Pradhan
One clever developer asked the question: What would an emoji town look like? The result is a fun, flat and animated world. It’s a great mix of modern technology and retro-game looks.
See the Pen
3D Emoji Town (Pure CSS) by George W. Park
Not a fan of the run-of-the-mill emoji characters? Then build your own! This tool lets you choose from various skin tones, facial features and even accessories.
See the Pen
Emoji Factory by Olivia Ng
You wonder if, thousands of years from now, archaeologists will equate emoji with ancient Egyptian hieroglyphics. Granted, emoji are probably more lighthearted and reflect modern times. But both are used to communicate a story.
Beyond those academic arguments, emoji can be just plain fun. Especially when spiced up with a little CSS and JavaScript, like the examples above. Hopefully, they’ll get give you a laugh and get your creative juices flowing.
Want to see even more cute and fun emoji snippets? Take a look at our CodePen collection!
The post Show Me Emoji: Iconic Code Snippets appeared first on Speckyboy Design Magazine.
