PHP Firebass Cloud Messaging (New)
Read more at https://www.phpclasses.org/package/10998-PHP-Send-push-notifications-using-Google-Firebase.html
Are you dreaming of setting up your own social media site, or creating a social media app for a mobile phone? Another open source software has been added to the Free Social Network / Media Software page. Now you can create a website with interactive social features that allow people to share stuff with each other, without having to write your own software from scratch.
Save the date! The next WordCamp US will be held on November 1-3, 2019, in beautiful St Louis, Missouri. One of our largest events of the year, WordCamp US is a great chance to connect with WordPress enthusiasts from around the world. This is also the event that features Matt Mullenweg’s annual State of the Word address.
We’d love to see you in St. Louis next year, so mark your calendar now!
WordPress 5.0.1 is now available. This is a security release for all versions since WordPress 3.7. We strongly encourage you to update your sites immediately.
Plugin authors are encouraged to read the 5.0.1 developer notes for information on backwards-compatibility.
WordPress versions 5.0 and earlier are affected by the following bugs, which are fixed in version 5.0.1. Updated versions of WordPress 4.9 and older releases are also available, for users who have not yet updated to 5.0.
Thank you to all of the reporters for privately disclosing the vulnerabilities, which gave us time to fix them before WordPress sites could be attacked.
Download WordPress 5.0.1, or venture over to Dashboard → Updates
and click Update Now
. Sites that support automatic background updates are already beginning to update automatically.
In addition to the security researchers mentioned above, thank you to everyone who contributed to WordPress 5.0.1:
Alex Shiels, Alex Concha, Anton Timmermans, Andrew Ozz, Aaron Campbell, Andrea Middleton, Ben Bidner, Barry Abrahamson, Chris Christoff, David Newman, Demitrious Kelly, Dion Hulse, Hannah Notess, Gary Pendergast, Herre Groen, Ian Dunn, Jeremy Felt, Joe McGill, John James Jacoby, Jonathan Desrosiers, Josepha Haden, Joost de Valk, Mo Jangda, Nick Daugherty, Peter Wilson, Pascal Birchler, Sergey Biryukov, and Valentyn Pylypchuk.
2018 has certainly been an exciting year for WordPress. The CMS celebrated its 15th birthday and released its revolutionary version 5.0, featuring the new Gutenberg block editor. It seemed like there was something new to discuss on a daily basis. A lot of it was controversial.
As someone who uses WordPress and cares about its future, I followed the process to develop and release version 5.0 closely. There were all kinds of dramatic twists and turns in the story. Timelines for the release continually shifted, the choice of using React.js was put in doubt due to licensing issues and accessibility concerns arose.
So much was left up in the air and many of us on the outside were left to scratch our heads. That lack of certainty led many members of the community to vent their frustrations in one way or another. Personally, I took a liking to Gutenberg but was a bit perplexed by how everything was unfolding.
To be blunt, the whole situation was stressful. And, judging by the social media and blog posts I read, there were others who felt similarly.
For me, much of the concern was how this was all going to affect both my clients and workflow. Not knowing when Gutenberg would be released brought a fear of not being fully prepared for the change. And it also provided an air of uncertainty with projects currently under development. Should I build them with Gutenberg or keep the Classic editor?
To a certain degree, we build websites knowing that they aren’t going to last forever. Software changes and our tools of choice are subject to change. But this experience compressed everything into a day-to-day drama that wreaked havoc on my thought process.
And, now that WordPress 5.0 has finally come out, I wonder if I wasted too much brain power (of which I have very little in reserve) worrying about this whole thing. I also question why it had me so worked up in the first place.
WordPress is billed as a means to “democratize” publishing. And that in itself makes me think about having a voice (however small) in its future direction. Seeing the somewhat chaotic way 2018 unfolded left me feeling completely out of control – even though I really didn’t have any to begin with.
But the uncertainty surrounding this release made it nearly impossible for designers and developers to accurately communicate the changes with clients. If we didn’t know what was happening, how could we pass reliable information on to anyone else?
I think that’s why some people chose to speak out in whatever form they thought necessary. While WordPress is free software, many of us make a living with it. So, it’s reasonable to be concerned when you’re unsure of the effect impending changes will have on you or even when they will occur at all.
In the end, though, all the worrying did was make daily life that much more difficult. Watching my Twitter feed in the days leading up to the final release only heightened the sense of tension I felt.
The unhealthy mix of anger, frustration and messages of impending doom made me dread waking up on release day. I wonder how many of my fellow freelancers felt the same way.
It’s important to know what’s going on. Whether it’s world events or changes to your favorite CMS, knowledge is preferable to the alternative.
Participation is also crucial. If those who develop WordPress don’t know how we’re using it and what our concerns are, they’re not going to have the information they need to make the right decisions.
But I believe there is a line between involvement and unhealthy obsession. Getting caught up in the daily minutiae, at least as an outsider, seems very much counterproductive. Why waste energy on something I have zero control of?
In the year ahead, I want to make a change. I’m still going to pay close attention to the latest happenings in the world of WordPress. But I’m not going to sweat all the inner-politics of how things get done. I’ll let that to those who are directly involved.
Instead, I plan to focus on using the software to the best of my abilities while continuing to evolve with it. That is, after all, the fun part. And it’s why I started using WordPress in the first place.
The post What WordPress 5.0 Taught Me About Stress appeared first on Speckyboy Web Design Magazine.
A friend emailed me recently asking about route specific configuration in Slim. He wants to be able to set properties when creating the route that he can pick up when the route is matched. The way to do this is using route arguments. I've written about route arguments before in the context of setting default values for a route parameter, but you can also use them to set new data for use later.
In this post, I'm going to look at how to use them for configuration data, such as setting required ACL permissions for routes.
To recap, we set an argument on a route using setArgument() and like this:
$app->get('/widgets/{id}', HelloAction::class) ->setArgument('permission', 'canReadWidgets');
We have added a new argument, permission, to the route's arguments and given it a value of canReadWidgets. As the name "permission" is not in the path arguments, it cannot be overridden.
We want to access the value of the permission in middleware, so let's use group middleware:
$app->group('', function ($app) { $app->get('/widgets/{id}', HelloAction::class) ->setArgument('permission', 'canReadWidgets'); // other routes that need an ACL check here })->setMiddleware(AclCheckMiddleware::class);
We can now use getArgument() to retrieve the permission and see if the user is allowed to continue.
$route = $request->getAttribute('route'); $permission = $route->getArgument('permission', 'canDoNothing');
That is, we retrieve the Route object from the Request and then grab the argument. The second parameter to getArgument() is the default value to return if there is no argument set on the route.
To see it in context, the bare-bones AclCheckMiddleware code might look something like this:
class AclCheckMiddleware { public function __invoke($request, $response, $next) { $user = $request->getAttribute('user'); // set in an earlier middleware // retrieve the configured permission value $route = $request->getAttribute('route'); $permission = $route->getArgument('permission', 'canDoNothing'); if ($this->user->isAllowed($permission) === false) { return new Response(StatusCode::HTTP_FORBIDDEN); } return $next($request, $response); } }
Note that for group or per-route middleware this works out-of-the-box. If the middleware is added using $app->add(), then you'll need to set the configuration setting determineRouteBeforeAppMiddleware to true so that the route attribute exists when the middleware is run.
There you have it. The same mechanism used for setting a default route argument can also be used for per-route settings. This is incredibility useful for situations like ACL permissions checks and I'm confident that there are many more equally useful things that can be done.
Some designers take great pride in starting every project from scratch. They are successfully seeing it through to the end. Others have no problem using whatever tool or aid they can get their hands on. Such tools will help them meet their objectives.
Neither group is wrong. Something worth bearing in mind, however, is when you start from scratch, you’d better know what you’re doing.
Gaining the experience you need to become a professional web designer takes time. Acquiring a strong sense of creativity also takes time. Creativity is rooted in knowledge. You can’t think outside the envelope if you don’t know what the envelope looks like.
Many experienced designers aren’t one bit shy about using pre-built website. They can help them get projects underway.
As you will see.
The problem with these statements is that neither is true. This is for the simple reason that creating designs from scratch and creativity are not one and the same. To be creative you first have to establish a foundation of knowledge. It should address the various aspects of web design. Without that knowledge, you’ll be setting standards for yourself you’ll be unable to meet.
You first need to understand what best practices are (the aforementioned “envelope”). After you’ve gained that knowledge you can start to improvise. This is where creativity enters the picture.
A pre-build website can be a Godsend here because best practices are already embedded in it. You need to understand the workings of a pre-built website. You’ll begin to understand how to go about customizing them to get what you want.
Be Theme has a library of roughly 400 (and counting) pre-built websites.
Let’s look at a few to see how they can help to boost your creativity.
Impressed? Keep going; there’s much more to come.
You’re only professional if you design from scratch & Pre-built websites are for beginners
Here’s another fallacy. It should read like this. “You’re only a professional if you give your clients precisely what they want – every time”.
It is true that pre-built websites are excellent tools for beginners, but it’s true for others as well. As we touched upon previously, you can learn a lot by using them. It is especially so when the content matter relates to the industry sector you’re not familiar with.
Even if you’re an advanced designer, pre-built websites can be a great help in broadening your client base.
For example, a client might be looking for a simple yet powerful way to get a message across. In this case, you don’t want to create a stunning website filled with eye-candy and special effects. Any one of the following would be a far better choice:
“Simple” isn’t it? And quick.
Remember the times when you were a student. Did you allocate an equal amount of time to completing each of 4 homework assignments? How about 35 minutes for each one? If so, it didn’t work very well, did it? Reading a chapter from your English Lit textbook or solving 10 Calculus problems? These won’t necessarily take the same amount of time. You take whatever time it takes to complete the assignment.
It’s the same with your clientele. Some are more demanding than others. Some deadlines are tougher to meet than others. Some represent industry sectors you know zero about, or close to it.
You can’t afford to give multiple clients equal time. Pre-built websites will help in that they can dramatically speed up your workflow. No matter what industry sector or website type you’re dealing with.
Working with a pre-built website is something like having a team member give you a hand. For that matter, if you use pre-built websites and are part of a team, you’re in pretty good shape.
Imagine you had projects to work that addressed these four diverse areas. We’ll bet you could handle them all at once reasonably easy if you have pre-built websites to help you out.
And, at the end of the day, you’ll be just a little bit smarter and a little bit more creative.
Conclusion
Do you like the idea of taking on a complex assignment? How about creating your design starting from scratch? Nothing wrong with that, and should you run into a problem you’ll know you don’t have to brute force your way through. You might risk ending up with a result that’s not as satisfying as you’d hoped for.
You’ll do best when you choose your battles. Use pre-built websites when they clearly present the best option. Use them when your knowledge in a certain area is lacking. Same goes for when you’re unsure of the design standards or latest trends involved.
The secret here is that your typical pre-built website has a hidden value. You might not be aware of it until you put it to use. Start by browsing Be’s library to get a better idea of how these hidden values can help you in your work.
The post Designing from Scratch vs Pre-built Websites: Is One Better Than the Other? <span class="sponsored_text">Sponsored</span> appeared first on Speckyboy Web Design Magazine.
I recently was asked to add a git hook to our main repository to add the Jira issue number to the commit message in an automated way. We were so far handling this really inconsistently, with many commits not having the ticket number at all, while others would have them either at the start or the end of the commit message. Since our branches all contain the ticket number (naming is like `feature/APP-123-this-new-feature) this should be easy, right?
Searching around I found that Andy Carter has already published a hook written in Python to do just this. I copied the script and put it in the prepare-commit-msg file. Because I work on Windows these days I expected #!/usr/bin/env python
not to work so I updated it to be #!C:\Program Files\Python\Python.exe
.
I started testing my new hook, but it wouldn't work. I would constantly run into an error when committing: error: cannot spawn .git/hooks/prepare-commit-msg: No such file or directory
.
After trying many different things including adding quotes to the shebang, just using python.exe
(since Python was added to the PATH) and a few other things, I found out that I had simply been too excited to change the script. It turns out Windows does support #!/usr/bin/env python
. So after simply changing the shebang back to it's original value the commit hook worked like a charm!