In a hilarious read in the Australian Financial Review, a propaganda piece disguised as an article on remote work and office perks has been published titled WFH raises the bar for offices.
I meant to post this last year, so this has been sitting in my drafts. But I found it so comical and biased that I felt compelled to write about it.
Mirvac, a large Australian property developer with a vested interest in getting people back into the office (because it also owns commercial real estate), has set up a trial space for clients and architectural firms. But, showing just how out of touch they are, a paragraph in the linked story reads.
PHP, the programming language that has been declared dead more times than a cat has lives, is still very much alive and kicking. Despite what some elitist developers may say, PHP is not going anywhere anytime soon.
Despite all the naysayers constantly predicting its demise, PHP continues to chug along, powering some of the biggest websites on the internet.
Let’s start by taking a look at the statistics. According to W3Techs, PHP is currently used by 78.9% of all websites with a known server-side programming language. That’s a pretty impressive number, considering that PHP has been around since 1995. To put it in perspective, that’s longer than some developers have been alive. And the reason why it has been around for so long is that it just keeps getting better.
If you have been a reader of my blog for a while, you would know that I am an avid cryptocurrency enthusiast. I believe in the tech more so than the financial side. I find blockchains fascinating because, despite their perceived complexity, you can implement a blockchain in any programming language; Javascript included.
I thought it would be fun to create a blockchain using TypeScript and then iteratively change the code to offer more flexibility, such as the ability to add metadata into the blocks and query the blocks themselves.
In a recent project, I worked with Markdown files that contained metadata at the top for blog posts. I needed to parse the Markdown with JavaScript and make a set of key/value pairs.
As you can see, the metadata is encapsulated in – – – with the metadata contained within.
// Function to parse metadata from a markdown file const parseMarkdownMetadata = markdown => { // Regular expression to match metadata at the beginning of the file const metadataRegex = /^---([\\s\\S]\*?)---/; const metadataMatch = markdown.match(metadataRegex); // If there is no metadata, return an empty object if (!metadataMatch) { return {}; } // Split the metadata into lines const metadataLines = metadataMatch[1].split("\\n"); // Use reduce to accumulate the metadata as an object const metadata = metadataLines.reduce((acc, line) => { // Split the line into key-value pairs const [key, value] = line.split(":").map(part => part.trim()); // If the line is not empty add the key-value pair to the metadata object if(key) acc[key] = value; return acc; }, {}); // Return the metadata object return metadata; }; You can call this function and pass in the markdown file content. It will return an object with the metadata.
In a WordPress project I am building, I needed a way to programmatically update the post status of a post on the edit screen, specifically in the Gutenberg editor.
Before arriving at the solution below, I first struggled to figure this out. I was trying to call the updatePost method with a post object and modified status, then calling savePost but what kept happening was the post would revert to draft status.
When WordPress introduced the Gutenberg editor, it was a mess, to say the least. Everything was turned upside for developers and things that worked in previous versions were completely broken when Gutenberg was released.
One of the things that were broken in WordPress was the ability to hide a meta box on the editor screen. Instead of setting meta_box_cb to false and expecting the box the hidden, nothing happens.
Well, there is a way you can hide meta boxes by using the following snippet of code inside of functions.php
The Advanced Custom Fields plugin for WordPress is invaluable. It has filled a gap in WordPress for the better part of a decade and is one of the first plugins that I install in a new WordPress installation (I have a lifetime developer licence).
The ACF plugin provides a Javascript API available using acf it has numerous methods for interacting with ACF fields in your WordPress installation. You can programmatically get and set field values, observe for changes and react accordingly.
In the beginning, I was one of the loud developers protesting WordPress Gutenberg. But, now that Gutenberg has been around for a while, I’ve grown to like it. I can’t tell if it’s because of Stockholm syndrome or if it has actually improved.
Anyway.
One of the looming problems users of WordPress will still face is the fact if you programmatically insert content into WordPress using wp_insert_post or however else you insert content (say from a CSV or API) you’ll find that WordPress will put it into a Classic Editor block. You will then be prompted to “Convert to blocks” in the editor.
There are many different ways to solve this use case. You want to wait for an element to exist on the page and run a callback function when it does. It seems simple enough, but what’s the easiest way?
By using an async function and a while loop, we can wrap setTimeout in a promise, then await it, and then resolve the promise when the timeout completes. As you can see, it will continue the loop until we reach the timeout passed into the function (or the element is found).
Remote work (also known as WFH) is a hot topic in 2022. As pandemic-era mandates and restrictions come to an end, there has been a new battle forming.
In the left corner, we have companies that want their employees to come back into the office, and in the right-hand corner, we have employees who have been allowed to work remotely for the last two years being asked to come back into the office.