FLOSS Project Planets

If you need to perform HTTP requests using Python, then the widely used Requests library is often the way to go. However, if you prefer to use only standard-library Python and minimize dependencies, then you can turn to urllib.request instead.

In this video course, you’ll:

• Learn the essentials of making basic HTTP requests with urllib.request
• Explore the inner workings of an HTTP message and how urllib.request represents it
• Grasp the concept of handling character encodings in HTTP messages
• Understand common hiccups when using urllib.request and learn how to resolve them

If you’re already familiar with HTTP requests such as GET and POST, then you’re well prepared for this video course. Additionally, you should have prior experience using Python to read and write files, ideally using a context manager.

In the end, you’ll discover that making HTTP requests doesn’t have to be a frustrating experience, despite its reputation. Many of the challenges people face in this process stem from the inherent complexity of the Internet. The good news is that the urllib.request module can help demystify much of this complexity.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

How to ensure a smooth Drupal 7 migration with content, design, and technology audits

In this article, we focus on tackling the organizational challenges that come with the technical realities of the migration away from Drupal 7 to newer, up-to-date versions of the content management system​​. We outline a strategic blueprint for a successful Drupal 7 migration, centered around three critical audits:

• Content audit: Evaluating which content should be carried over to the new platform.
• Design audit: Seizing opportunities to enhance the site’s design during the rebuild.
• Technical audit: Refining the site architecture and meticulously planning the technical aspects of the migration.

This is the perfect catalyst and opportunity for your organization to assess and not just transition, but to reconstruct your digital presence to meet your future goals and challenges.

As the clock ticks towards January 2025, the End of Life (EOL) for Drupal 7 looms on the horizon. Moving away from Drupal 7 marks a critical juncture. Since Drupal 8 and above are significantly different in architecture from Drupal 7, the move requires a comprehensive migration. The good news is that the upgrade paths from Drupal 8 and above are smoother, so the step up from Drupal 7 represents a unique, one-time effort, which will pay itself off in longer site life cycles and higher ROI on that investment.

The core principle guiding this migration strategy is the alignment of technical implementation and design with the initial content audit. This approach ensures that the rebuild is driven by content needs, rather than forcing content to conform to a predetermined site structure.

Some key organizational challenges issues when navigating this technical shift away from Drupal 7 revolve around governance, starting by understanding the existing content on your website, assigning responsibility for it, and ensuring its relevance and quality throughout the migration process.

This technical inflection point can and should also spark a broader debate about the extent of redesign and transformation needed during the migration. IT and marketing teams should be discussing, in a nutshell, “What do we have? What can be better? What do we need to make that happen?”

Palantir.net is a Drupal Association–Certified Migration Partner. We have the technical expertise, experience, and strategic insight required to help steer you through this vital transition. Whether through our Continuous Delivery Portfolio (CDP) or web modernization services, Palantir is ready to assist you in navigating the complexities of the D7 EOL upgrade.

Content audit: Decluttering the house

At the heart of any successful migration lies a well-executed content audit, a responsibility primarily shouldered by the Marketing team. This vital process streamlines the migration by identifying what content truly needs to be transferred to the new platform and what can be retired.

The essence of a content audit

The key questions to address during the audit are: What content do we need? What can we do without? These decisions should be data-driven, relying on analytics to assess the relevance and usage of the content. Key metrics include page views, content validity, and user engagement.

If you don’t like having a cluttered house, you don’t just decide to build a slightly bigger house, then move all your clutter into it. It would be a better idea to take a look at what’s actually cluttering your house first, then decide what you need to build. In the same way, letting content drive your technical decisions is the better approach.

The complexity of a given migration is often more dependent on the variety of different content types than the volume of content. Once a system for migrating a specific type of content, like blog posts, is developed, it can run autonomously while the technical team focuses on other content types. For this reason, a site with numerous content types requires a more intricate migration plan compared to one with fewer types. A content audit can help reduce the number of content types and with it the resulting effort needed.

Tips for conducting a successful content audit

 The following considerations can help make your content audit a smooth and effective process:

• Develop a comprehensive content inventory: Start by cataloging every piece of content on your website. This step is crucial as it allows you to see the full scope of your existing content and understand what requires improvement, discarding, or migration. Document key details of each content piece, such as URLs, titles, purpose, format, number of internal links, and other relevant information.
• Make data-driven decisions: Use tools like Google Analytics and Google Search Console to review content performance, examining metrics like traffic, engagement, bounce rates, time on page, and conversion rates. This quantitative analysis helps inform your content strategy and guides decisions on what content needs updating or removal.
• Complement data with qualitative decisions: Compare your content against benchmarks that align with your goals and audience needs. Assess the content for user experience, compliance with your style guide, and potential improvements. Decide on actions for each content piece, such as keeping, updating, consolidating, or removing, based on their relevance, quality, and performance.
• Involve a content strategist: An expert content strategist can help with all the above tasks and aid you in preparing a migration framework. They will help align your content with your marketing and branding goals, as well as UX design and information architecture. If you don’t have an internal content strategist, Palantir can provide one if we help you with your migration. 

Content as opportunity for a redesign

Conducting a content audit does more than just streamline the migration process. It can also unveil opportunities for a redesign of your site’s information and content architecture, aligned with a new content strategy. This process is not just about elimination, but also about discovery — uncovering what content is most valued by users. Not only are you finding out what you don’t need, but you’re hopefully finding out what's really important as well.

Given that moving from Drupal 7 to Drupal 10 essentially entails a complete site rebuild, there lies a golden opportunity to design the site around the content. This approach ensures that the site architecture complements and enhances the content, rather than forcing content to fit into a pre-existing structure.

The insights won here feed into the second crucial stage of a Drupal 7 migration: the design audit.

Design audit: An opportunity for enhancing UX

A design audit is where you and your Marketing team evaluate the current design’s effectiveness and explore the potential for a redesign. It goes hand-in-hand with a content audit.

Design audit objectives

• Evaluate current design effectiveness: Before deciding on a redesign, critically assess how well your current design serves your content and users. Does it facilitate easy navigation? Is it aesthetically pleasing and functionally efficient?
• Consider compatibility with Drupal 10: Drupal 10 brings new features and capabilities. The design audit of a Drupal 7 website usually reveals a rigid, template-based layout system, limiting content display versatility. By migrating to Drupal 10 and utilizing its advanced Layout Builder, the redesign can offer dynamic, user-friendly layouts, enhancing user engagement and providing flexibility for content strategy adaptations.
  
  Note that, while migrating away from Drupal 7, you essentially rebuild your site. Even if you choose to retain the existing design, adapting the look and feel to the newer Drupal version will require some level of reworking as well. If your existing design seems incompatible or would require extensive modifications, it might be more efficient to opt for a new design.
• Align design with content strategy: The design should complement and enhance the content, not overshadow it. A design audit should involve close coordination with content strategists to ensure that the design facilitates the content’s purpose and enhances user engagement.
• Explore modern design trends: Technology and design trends evolve rapidly. Use this migration as an opportunity to refresh your website’s look and feel to stay relevant and appealing to your audience.
• Accessibility enhancement: Focus on improving the overall user experience for everyone. This includes optimizing the site for various devices and improving accessibility, for instance, compliance with A11Y guidelines.

Palantir not only offers technical expertise in migration processes but also provides skilled designers who can seamlessly collaborate with your team. Our designers are adept at working alongside content strategists. They ensure that you end up with a cohesive system that effectively supports and enhances your content strategy, ensuring that every aspect of your site’s design is driven by and aligned with your overall content goals.

Technical audit: Engineering a future-ready framework

Next up, your internal IT team should perform a comprehensive technical audit. If necessary, this stage can overlap with the content audits. However, we recommend that your migration should be primarily driven by the insights gained from your content audit.

The ultimate goal of the technical audit is preparing for a new Drupal environment. This means understanding how the identified technical elements will function in the new system and planning for any necessary adaptations or developments.

Data architecture audit

The technical audit begins with a detailed analysis of how data is structured in the current Drupal 7 site. This involves examining the entity relationships and the architecture of data storage. Understanding how different pieces of content are interlinked and how they reference each other is essential. This step not only overlaps with the content audit but also sets the stage for a smooth technical transition to Drupal 10.

Custom functionality and integration evaluation

A critical aspect of the technical audit is assessing any custom functionalities or third-party integrations present in the current system. This includes custom plug-in modules, single sign-on mechanisms, and other unique features. Each custom element that you migrate over is something you have to maintain, potentially throughout the lifetime of the site. The decision to migrate these elements should be based on their current value and necessity. During the audit, aim to determine which functionalities are essential and how they can be adapted or redeveloped for Drupal 10.

Driving collaborative decision-making

Collaboration between the IT/technical, marketing, content strategy, and design teams is vital in deciding what to keep (and migrate) and what to discard — regarding site content, architecture, code, and functionality. The technical audit, outlining the functionalities and integrations of the current site, guides the planning and decision-making process following the insights you gain from the content and design audits.

Conclusion: Charting the course of a Drupal migration

As we’ve seen, the journey away from Drupal 7 involves three main audits:

• the content audit, which acts as a decluttering exercise;
• the design audit, seizing opportunities to enhance user experience;
• and the technical audit, engineering a future-ready framework. 

The content audit is the central pillar, and content strategy should drive the technical implementation and design decisions. This approach ensures a migration process where content seamlessly integrates into an efficient, updated site structure, rather than being confined by it.

Palantir is here to help and guide you through a successful migration from Drupal 7 to the future of your online digital presence. We are a Drupal Association–certified migration partner, with years of experience with intricate processes. Our expertise in content strategy, design innovation, and technical proficiency makes us an ideal full-service partner for navigating the complexities of a D7 end-of-life upgrade.

If you’re considering this critical step in your digital strategy, we invite you to explore how Palantir’s Continuous Delivery Portfolio (CDP) and web modernization services can transform your digital presence.

Content Strategy Design Drupal Drupal CDP Strategy

Media has changed a lot with new technology. Organizations need to connect with their audience using modern methods. Big media companies use digital tech to reach people on different platforms and make more money.

Top media networks have many websites and social media pages to reach more people. They create websites for different groups. In the age of Web 3.0, having a strong online presence is crucial. Drupal helps with that, improving the customer experience and increasing conversion by 25% for one media client we worked with.

Why is Drupal Preferred Over Other CMS? 

Media relies on content, and that content needs to bring in revenue in a scalable way. To achieve this while keeping things easy to manage, you need the right Content Management System (CMS). Considering the constant flow of new content, choosing the right CMS is crucial.

Today we've issued 5.0.1 and 4.2.9 bugfix releases.

The release package and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is Mariusz Felisiak: 2EF56372BA48CD1B.

Are you early in your software dev or data science career? Maybe it hasn't even really started yet and you're still in school. On this episode we have Sydney Runkle who has had a ton of success in the Python space and she hasn't even graduated yet. We sit down to talk about what she's done and might do differently again to achieve that success. It's "The Young Coder's Blueprint to Success" on episode 444 of Talk Python To Me.<br/> <br/> <strong>Links from the show</strong><br/> <br/> <div><b>Sydney Runkle</b>: <a href="https://www.linkedin.com/in/sydney-runkle-105a35190/" target="_blank" rel="noopener">linkedin.com</a><br/> <b>Pydantic</b>: <a href="https://pydantic.dev" target="_blank" rel="noopener">pydantic.dev</a><br/> <b>Code Combat</b>: <a href="https://codecombat.com/play" target="_blank" rel="noopener">codecombat.com</a><br/> <b>Humanitarian Toolbox</b>: <a href="http://www.htbox.org" target="_blank" rel="noopener">www.htbox.org</a><br/> <b>PyCon 2024</b>: <a href="https://us.pycon.org/2024/" target="_blank" rel="noopener">pycon.org</a><br/> <b>Good first issue example</b>: <a href="https://github.com/pydantic/pydantic/labels/good%20first%20issue" target="_blank" rel="noopener">github.com</a><br/> <b>Watch this episode on YouTube</b>: <a href="https://www.youtube.com/watch?v=LtEYowIazVQ" target="_blank" rel="noopener">youtube.com</a><br/> <b>Episode transcripts</b>: <a href="https://talkpython.fm/episodes/transcript/444/the-young-coders-blueprint-to-success" target="_blank" rel="noopener">talkpython.fm</a><br/> <br/> <b>--- Stay in touch with us ---</b><br/> <b>Subscribe to us on YouTube</b>: <a href="https://talkpython.fm/youtube" target="_blank" rel="noopener">youtube.com</a><br/> <b>Follow Talk Python on Mastodon</b>: <a href="https://fosstodon.org/web/@talkpython" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>talkpython</a><br/> <b>Follow Michael on Mastodon</b>: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>mkennedy</a><br/></div><br/> <strong>--- Episode sponsors ---</strong><br/> <a href='https://talkpython.fm/training'>Talk Python Training</a>

Once upon a time, at a conference, the lead developers from a selection of frameworks sat down in the same room and agreed on some standards for all their projects to use. The aim was to make PHP frameworks and libraries easier to combine for users. That is when php-fig: the PHP Framework Interop Group was born. This group of awesome individuals oversees the PHP Standards Recommendations (PSRs). The PHP Standard Recommendation (PSR) is a PHP specification published by the PHP Framework Interoperability Group (PHP-FIG). It serves the standardization of programming concepts in PHP. The aim is to enable interoperability of components. The PHP-FIG is formed by several PHP frameworks founders. Dive into this article to learn about different PSRs and how you can adhere to them. PSR-0 & PSR-4 These describe a specification for auto loading classes from file paths. PSR-0 and PSR-4 are both standards concerning namespaces, class names and file paths. This PSR also describes where to place files that will be autoloaded according to the specification. Auto loading Autoloading is a functionality to help developers including  PHP classes automatically without writing cluttered include/require statements everywhere.In PHP, class's definition is loaded with require or include statements in the files they are being called i.e., prior to using it as shown below.  include 'Utility/Test Example.php'; $exampleObj = new TestExample(); The above approach raises some issues as if we have tens of external classes to be used in a file and we start writing lines of require/include statements right at the beginning of a source file.  To overcome this issue PHP 5 introduced the magic function __autoload() which is automatically called when your code references a class or interface that hasn’t been loaded yet. void _autoload (string $classname);Here’s an example of a basic __autoload() implementation:  <?php function _autoload($className) { $filename = 'Utility/’ . $className . '.php'; if (is_readable($filename)) {The major drawback to the autoload() function is that you can only provide one autoloader with it. PHP 5.1.2 introduced another autoloading function (spl_autoload_register) for coping with_autoload 's limitation. The major drawback to the __autoload() function is that you can only provide one autoloader with it. PHP 5.1.2 introduced another autoloading function (spl_autoload_register) for coping with __autoload 's limitation.  The introduction of spl_autoload_register() gave programmers the ability to create an autoload chain, a series of functions that can be called to try and load a class or interface.  For example: require $filename; } } $exampleObj= new TestExample(); <?php function utilityAutoloader($className) { $filename = 'Utility/’ , $className '.php'; if (is_readable($filename)) { require $filename; } } function functionAutoloader($className) { $filename = 'Functions/’ . $className . '.php'; if (is_readable($filename)) { require $filename; } } spl_autoload_register('utilityAutoloader'); sp1_autoload_register('functionAutoloader');Autoloading was  such a great idea that every project started to use it. Inevitably everyone created their own version of autoloader as uniform standards were lacking. Clearly, PHP desperately needed a standard for autoloader, which is how PSR-0 was born. The latest accepted autoloader standard is PSR-4.  PSR-0 (Autoloading Standard) Overview of PSR-0: A fully-qualified namespace and class must have the following structure \\(\)* Each namespace must have a top-level namespace (“Vendor Name”). Each namespace can have as many sub-namespaces as it wishes. Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system. Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace. The fully-qualified namespace and class are suffixed with .php when loading from the file system. Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lowercase and uppercase. Examples: \Doctrine\Common\IsolatedClassLoader =>/path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php \Symfony\Core\Request =>/path/to/project/lib/vendor/Symfony/Core/Request.php PSR-4 (Autoloading Standard) Overview of PSR-4: The term “class” refers to classes, interfaces, traits, and other similar structures. A fully qualified class name has the following form:\(\)*\ The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”. The fully qualified class name MAY have one or more sub-namespace names. The fully qualified class name MUST have a terminating class name. Underscores have no special meaning in any portion of the fully qualified class name. Alphabetic characters in the fully qualified class name MAY be any combination of lowercase and uppercase. All class names MUST be referenced in a case-sensitive fashion. Example for PSR-4 based Autoloading using Composer: Consider the following directory structure to achieve PSR-4 based autoloading using composer. Create a composer.json file using composer init. If not, you can create one manually now in your project’s root. specbee@specbee-HP-ProBook-640-G1: /var/www/html/psr$ touch composer.json Set up PSR4 autoloading by editing the composer.json file as shown below: { “autoload” : { “psr-4” : { “Codecourse\\’ : “src/” } } } Here, CodeCourse is a vendor name of your application, you can use this name while namespacing files inside of your src directory ,such as: namespace CodeCourse\Filters;Or namespace CodeCourse\Repositories;          etc, And src is your application’s directory that you want to autoload. Next, open up your terminal and type in the following command to install autoloading files in your project.This will generate the vendor directory and autoload.php file inside of it. specbee@specbee-HP-ProBook-640-G1:/var/www/html/psr$ composer dump-autoload -0 Let’s first create a couple of classes inside of the CodeCourse directory. Create AuthFilters.php inside CodeCourse/Filters The above example causes a side effect, i.e., loading a file named “file.php”. Files must be in UTF-8 without BOM(Byte Order Mark). Namespaces and class names must follow the standards in PSR-0 and PSR-4. Here is an example that illustrates the basic naming conventions for properties, classes, and methods. <?php class Classname { public $firstProperty; //Don’t declare multiple properties in a single line public static $StaticProperty; public function firstMethod() { //definition… } } ?>PSR-2 (Coding Style Guide) Overview of PSR-2: You must follow the PSR-1 coding standards. 4 spaces must be used for indents. Using tabs is not allowed. There is no limit to line length, but it should be under 120 characters, and best if under 80. There must be one blank line after namespace declaration and there must be one blank line after the block of use declaration. Opening curly braces for classes and methods must go on the next line and closing curly braces must go on the line after the body. Methods and properties must be defined with abstract/final first, followed with public/protected, and finally static keyword. You must not put a newline before curly braces in conditional statements. You must not put any spaces before ( and ) in conditional statements. An example for defining classes: You must open the curly braces on the new line and the extends and the implements keyword must be used in a single line. <?php class ClassName extends ParentClass implements InterfaceName { //class definition… } ?>If there are multiple interfaces to implement, then you can write the interface names in the new line as shown below: <?php class ClassName extends ParentClass implements InterfaceName1, InterfaceName2, InterfaceName3 { //class definition.. } ?>Example to show how methods are defined in PHP:While defining the methods, the arguments should be written in the same line. Also, you must not put any whitespaces before commas in arguments, and you must put one whitespace after them. <?php class ClassName { public function method($arg1, $arg2) { //definition… } } ?>If there are many number of arguments, then they can be written in newline one after the other: <?php class ClassName { public function method( arg1, arg2, arg3) { //definition… } } ?> When defining methods, you must have either one of public/protected/private and abstract/final. The visibility modes come after the abstract/final keyword, if used. static is the last modifier. <?php class ClassName { abstract public function abstractMethod(); final public static function staticMethod() { //definition… } } ?>Conditional Statements You must put one whitespace before ( You must not put any whitespaces after ( You must not put any whitespaces before ) You must put one whitespace after ) use elseif rather than else if. Example to show the difference between elseif and else if:Interpretation of elseif: <?php if ($condition1) { //… } elseif ($condition2) { //… } else { //… } ?>Interpretation of else if: <?php if ($condition1) { //… } else { if (condition2) { //… } } ?>For the switch statements,  The curly braces must be opened in the same line where the switch statement is written. The case body must be indented once from the case and the case must be indented once from the switch. Use no break when break is not needed. You can also use return instead of break. Example: <?php switch($condition) { case 0: echo ‘Use a break’ ; break; case1: echo ‘If you are not using break; then write no break as a comment’ ; // no break case 2: echo ‘Use return instead of break’ ; return; default: echo ‘Default’; break; } ?>Huge shoutout to Samvada Jain for her contributions to this article. Final Thoughts In a project that is incorporated with various packages, it can be a mess if each individual uses a different coding standards. This is the reason why PSR was designed. In total, there are over 20 PSRs that are designed and each PSR is suggested by members and voted according to an established protocol to act consistently and in line with their agreed upon processes. Our expertise in PHP stems from our focus on Drupal - An enterprise CMS built using PHP. If you are looking to develop a custom module for Drupal or any other Drupal development services, talk to us today!