Use Docker-Compose To Start A Lightweight Virtual Machine Container of Locally Installed WordPress

I’m not a Docker guy because I don’t use it often. Basic commands such as “docker ps” are probably new to me, meaning I can’t easily remember them. Regardless, there are plenty of online resources for me to tap into regarding Docker, so I’m not too fretted about forgetting what command to use with Docker. Today, I found a fun Docker activity. Yep, you can already see I’m a Docker noob. Regardless, this activity is about creating a docker-compose file, then spinning up Docker to start all services that run a locally installed WordPress. This docker-compose file could be found on the Internet easily! I got a very fast Internet connection too, and so it took Docker about a minute or two, I think, to just pull the latest WordPress and MySQL 8 (or 5.7 if you want to use this version) images down to my local machine – and just a few more seconds to start the whole locally installed WordPress up.

Why is it fun to do this? Well, I’m not a PHP developer! This means I can’t just write any PHP script to take care of whatever itch I have with WordPress. WordPress is based on the PHP programming language. I am though love to code in Python, and so I thought — hmm… what if I want to Djangorize WordPress? This means, I want to export all WordPress blog posts I have on a WordPress website of mine to a Django blog web app that I will code soon – but I have way too many WordPress blog posts! The problem is I’m not also an XML guy, and so WordPress’s export file I downloaded gives me pause. Although XML’s basic rules aren’t hard – because it’s an extensive markup language – meaning tags are extensive (not restrictive like HTML) – meaning you can make up your own tags pretty much. For example, in HTML, you can only use a built-in tag such as <div></div>, but in XML you could just make up a tag like <friend></friend>. Anywho, but the XML file I downloaded from WordPress’s export (exported my WordPress blog posts) is so huge and long – one look at it I got confused. So, my original solution is to use docker to start a local WordPress up, import the export XML file from the WordPress XML file download earlier – and then just export all the blog posts to CSV. See, I can’t export WordPress blog posts directly to CSV earlier because I’m not hosting my own WordPress, but I’m using’s official WordPress hosting service; these guys don’t allow you to export your blog posts to any other format besides XML. Unfortunately, if I want to use local WordPress to import XML and then export to CSV file format, I have to pay for a WordPress plugin – which I don’t want to do! Regardless, it was fun to do docker-compose!

So, what now? I kick myself a bit because now I remember that Python got Pandas that can read XML files. So, I went to all the troubles with docker-compose for naught. On the plus side, I got a local backup of my current running WordPress blog. Hooray! Anyhow, I’ll use Python, Pandas, and BeautifulSoup to organize the XML blog post data to my liking in the future, and in this way, I’ll able to write a Python script that allows me to import WordPress blog posts to Django’s blog web app. For now, I’ll leave you with a fun docker-compose file that allows you to start up a docker container that contains essential running services like MySQL to let you play with a locally installed WordPress.

One more thing, you need to download Docker yourself before you can use this docker-compose file. Once downloaded and install Docker, create a new folder on a Windows machine and name it “wordpress-local”, but you can name this folder with whatever name you like. Copy and paste the docker-compose file below to a file in this “wordpress-local” folder – and save this file as “docker-compose.yml”. Open up Windows PowerShell terminal, change into the “wordpress-local” folder using commands like “cd C:\Users\your-user-name-here\wordpress-local“, make sure the “docker-compose.yml” file is in “wordpress-local” folder, and then you can do “docker-compose up -d” in the terminal. This will tell Docker to start pulling in images for the latest WordPress and whatever version MySQL you had coded in “docker-compose.yml” file, and then Docker will install these images, and start services to allow you to go to to install WordPress locally. The volume Docker creates will be persisted, but you can do “docker-compose down --volume” in the terminal to delete all persisted Docker volumes. If you just do “docker-compose down”, then only Docker containers get deleted but not the volumes. It is fine that Docker containers get deleted because Docker is meant to be used this way – all it takes for you is to do “docker-compose up -d” to recreate and start the container again.

Docker compose file is below:

version: '2.12.2'

       - db
     image: wordpress:latest
       - wordpress_files:/var/www/html
       - "80:80"
     restart: always
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress

     image: mysql:8
       - db_data:/var/lib/mysql
     restart: always
       MYSQL_ROOT_PASSWORD: root-abcdefg
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: abcdefg

The line where the “docker-compose.yml” file said “version: ‘2.12.2’, you can change it to your docker-compose version. In the terminal, do “docker-compose --version” to see your current docker-compose version. The password for WORDPRESS_DB_PASSWORD and MYSQL_PASSWORD needs to be the same – because the former one is for environment settings and the latter one is the actual password that you want to set with MySQL database. You can also change the password for MYSQL_ROOT_PASSWORD to something else if you like. Oh, I almost forgot, when trying to import WordPress blog posts from the download of WordPress’s export XML file, if your file is too big, WordPress may refuse to import the blog posts. This can be fixed easily.

First, you need to install nano or vim for the Docker container. You do not need to stop the running Docker container to do this. In the terminal, do “docker ps” to see the Docker’s CONTAINER ID. In the terminal, do docker exec -it enter-the-container-id-here bash -c "apt-get update && apt-get install -y nano". Once everything is done, you can do “docker exec -it enter-the-container-id-here /bin/sh“. This allows you to mimic how you would ssh into a Linux server, but in our case, we go inside the container. Now, you can do “nano .htaccess“. Go to the very end of the file (.htaccess), and type in two lines:

php_value upload_max_filesize 256M
php_value post_max_size 256M

Save the .htaccess file. You can also create phpinfo.php file by doing “nano phpinfo.php“.


Save the phpinfo.php file. Exit the container’s ssh-like environment by doing Ctrl-d on the keyboard. Now, you can go to to see if upload_max_filesize and post_max_size are actually 256 Megabytes. You can always increase the Megabytes sizes for these two php_values so WordPress can allow the importation of larger WordPress exported files. That’s it! Go ahead and import your blog posts to a local container and play around with locally installed WordPress using Docker. Have fun!

We Got One Universe, Why Can’t We Have A Second One?

We got one universe, but why can’t we have a second one? There are too many things we don’t know since we’re still too stupid!

For example, we don’t know what is really happening inside the black hole because we can’t go into the black hole to do an experiment. We can’t travel faster than light, meaning we can’t really go to the edges of the universe. Without knowing what is happening outside of our universe, we can’t really say we know enough to discard the idea of string theory!

Once in a while, there will be theory that blows our mind. For example, in this case we’re talking about string theory. I think we’re too foolish to close our minds from string theory.

Once upon a time, the ancient people discarded the idea that the atom is real, but now we all know that atom is very real. This example should give us pause to see why we should not be too quickly to discard the string theory.

Once in a while, fear not, because there will be an Einstein comes along who will work out the math/science to prove that a crap theory is a crap theory. So, if string theory is full of crap, such a person will prove it to be so, but if it’s the juicy stuff — we will know, right? Meanwhile, I think we should be more open mind since we don’t know enough, eh?

What I’d written above was meant as a comment for “Should we abandon the multiverse theory? | Sabine Hossenfelder, Roger Penrose, Michio Kaku” YouTube video, but somehow YouTube refused to post my comment. Anywho, I’m posting this on my blog instead. Check the video out right after the break.

Django Was Rude But Now Seems Friendlier!

The last time I praised Flask over Django, I decided to tinker with Django a lot more. Lately, I have become warmer to Django by a lot. Now, I see Django is quite fun to program with. Although I could see Django is scary to beginner Python programmers, it’s not that hard at all if you tinker with it long enough. For example, Django could look scary to new Python programmers because they have to learn a whole new mature framework like Django – which means they have to know a whole new set of rules. Personally, at first, I hated how Django used different files for routing URLs. Nowadays, I think this is brilliant! I mean, nowadays, I instinctively know in the core project’s folder, I can include other apps’ in the that reside in the core project’s folder.

urlpatterns = [
    path('accounts/', include('account.urls')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

The code above is a snippet of the example code of in Django’s core project folder. The ‘accounts/’ part is how you navigate to your The include(‘accounts.urls’) part is where you tell Django, hey there are other url parts that you must join them with the accounts/ part to make a whole new URL that would route to a specific view that perform something for the app that uses ‘accounts/’ part. In my project, I named the app as account; in the main project folder’s I used path(‘accounts/’… to send visitors to account app, but I also told Django that it must look inside the inside the account app – this is why I used the part that said include(‘account.urls.’).

urlpatterns = [
    path('register/', views.register, name='register'),
    path('login/', views.login, name='login'),

The code above is a snippet of the example code of inside the Account app. By now, if you don’t know Django, you may get confused about why I keep saying app this app that. Basically, Django allows you to start a project which you can name however you want. Inside this project, you can create multiple apps. Each app should focus on a specific task that allows your whole project to perform brilliantly. For example, the account app in my Django project should have codes that focus on allowing visitors that come to my Django website to register, log in, visit Dashboard, and do a whole lot of things that are related to the meaning of having an account.

The snippet code of the inside the account app clearly shows that I created path parts for register and login. Meaning, a visitor who visits my Django website can register for an account by going to Same goes for login. The views.register or views.login part tells Django, hey you – you need to use the views from the inside the account app that got function based views with names like register and login. Of course, you can also use class based views inside, but it’s outside the scope of what I want to talk about in this post. Anyhow, the name=’register’ and name=’login’ parts tell Django, hey – whenever I return render(request, register.html, context) for the function-based view register (same goes for login) – if I use the register name inside any other template pages and doing something like {{ url ‘register’ }} or fully like:

<a href="{% url 'register' %}" class="s-btn s-btn-2 w-100">Register Now</a>

…this means Django should redirect or render the register.html page so the visitor could sign up for an account with my website. The same logic goes for login. Based on the examples above, you could basically see how simple it is to route requests to any HTML page as long you set the views to render the correct HTML pages – and then use the correct views’ names inside any HTML templated page.

Django is all about Model, View, and Controller setup (MVC). By this, I mean the structure of the Django project folder emphasizes a project folder first, app folder second, inside the app folder you got,,,, and whatnot. The important files are,, and – this should form the MVC pattern nicely.

The is responsible for allowing you to create models for the app. The allows you to create views for the app. The examples above show you that can render pages like register.html and login.html. More than just rendering HTML pages, the views can perform all sorts of logic such as calculating something, then allowing the calculation results to show up inside the rendered page such as — if you write a view for the cart.html page, you want to show the result of grand total which calculates the total cost of each item in the shopping cart including the shipping fee and sale tax. The allows you to route the requests to all sorts of places – for example, would allow the views to render HTML pages.

More about the Although you can create logic inside, some people prefer to keep the thin and create more logic inside the which makes the fat. This means the will contain more logic for the app than the For example, a Product model contains fields such as product_name, price, and other product-related fields. Yet, you can create a custom method inside the model to return whatever. This is a quick and easy way to allow any query to your model can also get a specific result back by also calling the method inside the model.

class Product(models.Model):
    product_name = models.CharField(max_length=255, unique=True)
    slug = models.SlugField(max_length=255, unique=True)
    product_description = models.TextField(max_length=2500, blank=True)
    stock = models.IntegerField()
    is_available = models.BooleanField(default=True)
    category = models.ForeignKey(Category, on_delete=models.CASCADE)
    created_date = models.DateTimeField(auto_now_add=True)
    modified_date = models.DateTimeField(auto_now=True)
    homepage_display = models.BooleanField(default=False)
    user_wishlist = models.ManyToManyField(Account, related_name='user_wishlist', blank=True)
    brand = models.CharField(max_length=255, blank=True, null=True)
    count_sold = models.IntegerField(default=0, null=True, blank=True)
    sku = models.CharField(max_length=100, blank=True, null=True)

    def get_url(self):
        return reverse('product_detail', args=(self.category.slug, self.slug))
    def __str__(self):
        return self.product_name

The snippet code of above is for a Product model in one of my Django’s projects. This model got a lot more custom methods and codes – but I just take a small snippet of the model to show you the example of creating a custom method get_url. This get_url method returns a product’s URL easily. For example, inside a store page (shop.html), you can:

{% for product in products %}
    <a href="{{ product.get_url }}">
    {% if product.image_1 %}
        <img src="{{ product.image_1.url }}" alt="{{ product.product_name }} image {{ }}">
    {% else %}
        {% if product.get_image_links_for_product_home %}
            <img src="{{ product.get_image_links_for_product_home.0 }}" alt="{{ product.product_name }} image {{ }}">
        {% endif %}
    {% endif %}
    {% if product.image_2 %}
         <img src="{{ product.image_2.url }}" alt="{{ product.product_name }} image {{ }}">
    {% else %}
         {% if product.get_image_links_for_product_home %}
             <img src="{{ product.get_image_links_for_product_home.1 }}" alt="{{ product.product_name }} image {{ }}">
         {% endif %}
    {% endif %}
{% endfor %}

You don’t have to get confused by the code above because what matters right now is the part where it says <a href=”{{ product.get_url }}”>. This is where I begin to create a link for the product’s images — I use <a href=””>images go here</a>, and inside <a href=””> I have {{ product.get_url }}. Remember? I had shown the example above where a method get_url got created inside the Product model.

def get_url(self):
        return reverse('product_detail', args=(self.category.slug, self.slug))

The line of code above specifically! You don’t need to understand every detail of this code because right now it’s more important for us to take note of what the code does. The code above returns a URL for a product. So, whenever you query the Product model to show a product, you can conveniently call the get_url along with it to get the URL of a product easily. This is why in the template of shop.html I can just do <a href=”{{ product.get_url }}”>product images go here</a> to allow a visitor to click on the images to go to a product’s detail page easily. I don’t need to go find the correct URL for each product and write a long URL out inside the <a href=”#”></a>part. This is why a lot of people are writing logic inside the to get things going their way. They prefer to write logic inside over because they can interact with the model inside the same .py file.

In summary, I think I rant on long enough, I think Django is scary for beginners, but Django can be rather safe for the beginners too — because Django would constantly deny the beginners from making mistakes — if a beginner makes a mistake Django won’t render anything but just errors. Nonetheless, this could be a source of frustration for some beginners as they see that they got too many errors that crash their Django project/apps. I think as long you tinker with Django long enough, you get familiar with how Django wants you to write your codes and smooths out the errors — you’ll be OK and have fun with coding with Django!

By the way, I just finished a Django project which you can now visit at Also, I made an advertisement for the website which you can check out right after the break. Enjoy!

I like Flask Framework For Web Application – Python Programming

I think Flask is an amazing Python framework because it is versatile and flexible. Although there is a drawback to using Flask instead of Django such as with Flask you have to implement many features that would come out of the box with Django. For example, with Django, you get a really good admin panel without any effort, but with Flask you have to write the whole admin panel yourself using Flask Security or Flask Login with Flask Admin — these packages together can help you to be able to code a completed admin panel that allows an administrator to do backend stuff and maintain the web application. With Django, the admin panel that comes out of the box looks very nice. Somehow though, perhaps I could be wrong but I’ve found Django’s admin panel, even with extensive personal customization, a heavy custom Django admin panel is still looking too similar to the one that comes out of the box. With Flask, since you have to code this yourself and depending on how much time and effort you put into the admin panel, it could look completely alien from one programmer’s Flask admin panel to the next.

I have learned Python for a couple of months or so, and I have found Flask is easier to work with than Django — I fondly remembered I started with Django first — and I had a hard time with making Django’s routing of internal paths to the way I like it. With Flask though, it’s simple as:

def home_page():
    custom code goes here
    return render_template('index.html', some_variable_to_pass_into_Jinja2_template=whatever)

The piece of code above would render an index.html page for a website using Flask. The decorator @app refers to the Flask app itself, and the route part is where the custom method home_page would render the template’s index.html page — in this case, the forward-slash (‘/’) would be a shortcut to render the index.html page. Now, let’s say you have a contact page where a web visitor could email you or so, how would you route this?

def contact_page():
    custom code goes here
    return render_template('contact.html', whatever=whatever, blah=blah, contact_form=contact_form)

So, when a visitor goes to ‘yourwebsite.yourdomain-name/contact — Flask would render the contact.html page.

I like how Flask routes internal paths like this because it’s so easy to see what is going on — not like Django’s black box. If you take a look at the custom code immediately after the @app.route, you would right away know that the block of codes belongs to what template’s page of the website.

I have heard a lot of people loved to use Flask for writing RESTful API, and I actually had done this once as a practice exercise. I could definitely see why people love Flask for this very purpose — it’s so easy to just jsonify the data using Flask. Once you have jsonify the data, you can totally choose how you would like to return these data when a request is made to the app using Flask. Nonetheless, recently I have been using Flask to just create small websites — not RESTful API — and this is fresher in my mind than doing RESTful API.

To sum it up, I just scratch the surface of what Flask can do in this blog post. Based on my own experience, I’ve found Flask is easier to work with than Django. Deploying the Flask web app felt easier than Django too. For example, once I’d finished writing a Flask web app, all I had to do was initialize a GitHub repository, commit, and push the web app to GitHub. Afterward, I could use Heroku or PythonAnywhere to host my Flask web app either through the free tier or paid tier. Setting up Flask with Heroku or PythonAnywhere isn’t that hard. The key is to do a double-check of the requirements.txt to make sure all required packages that Flask needs to run your web app are listed in this file. Heroku and PythonAnywhere rely on this file to install necessary third-party Python packages. Once you set up the necessary steps for Heroku or PythonAnywhere, the last thing you only have to do is to pull your app’s source from GitHub onto Heroku or PythonAnywhere. On Heroku’s CLI, you can just do [git push heroku main], and on PythonAnywhere Bash console you can just do [git pull].

Anywho, I just completed coding a Portfolio website using Flask. The main feature of this website is to allow a user to add various project showcases so he or she can show off the projects. The website relies on Bootstrap 5 and custom CSS I’d written — this means the whole website is responsive to various screen sizes, including mobile phones. In desktop mode, the website showcase two projects one at a time through the pagination feature — allowing visitors to flip to more projects by clicking next or back to previous projects. In mobile mode, I used lazy load to load the first few showcase projects’ images — then the rest would be loaded on-demand as the website visitors could forever scroll downward till all projects had been loaded. Check out the finished product on

How To Make Flask’s Flash Message Appears Only Once After User Is Logged-In!

I have been using Flask to work on a personal website for a couple of days. A small snag got me stumped for a while but I finally figured it out. In Flask, you could use flash to alert signed-in users or visitors about their status on your website such as they’d logged in or whatever… One drawback about Flask’s flash message is that it doesn’t go away unless you refresh the browser. Secondly, in the case of an authenticated user, the flash message indicates he’d logged in could appear again and again every time he or she visited the same page.

To solve the problem of Flask’s flash message isn’t going away, I employed JQuery to make the flash message disappear after nine seconds or so. This is easily done by using JQuery, so I won’t go into the detail of how to do this. What I want to talk about is how to make flash messages only appear once after a user is authenticated and logged in.

First, you need to install Flask-Session. Once you got Flask-Session installed, you need to import like so:

from flask_session import Session
from flask import session

Before you can use Flask-Session, you need to configure it to work with Flask.

# Flask-Session
app.config["SESSION_PERMANENT"] = False
app.config["SESSION_TYPE"] = "filesystem"
app.config['SESSION_USE_SIGNER'] = True

In a login section of your website/web app, you could do something like this after you execute a function or whatever you do to log the user in:

session['user_id'] =
session['flash_session_page_visit'] = 'page_visit'
flash(f'{} is logged in!', 'login message')

The session[‘user_id’] = is a Python line of code in which you want to store a user object’s property — that you called from the database — into a session which you named as user_id. The next trick is to create a new session out of the thin air just for the purpose of using a negation on it later. For this purpose I’d created ‘page_visit’ session which is just a bogus string, and then I stored this inside session’s flash_session_page_visit. The next step is to create a session_manager_func() as follow:

def session_manager_func():
    if current_user.is_authenticated:
        if not session.get('user_id):
            if not session.get('flash_session_page_visit'):
                flash(f'User Status:  {} is logged in!', 'user authentication status')

Now you can use the method session_manager_func() inside any Flask’s route to display any flash message just once after a user is logged in. This trick works because you use the negation keyword not to turn flash_session_page_visit into false. Since Flask’s session will be true and be available as long the browser isn’t closed, then this trick negates this session as if it isn’t there at all — this makes the flash message won’t appear twice as long as the browser isn’t closed, reopened, and then logged in again.

The current_user is the object got created by Flask-Login package that I imported for my program. Using Flask-Login I’m able to refer to any logged-in user as current_user either inside my Python script or in Flask’s Jinja HTML page. This makes me use my time more efficiently since I don’t really have to query the database for verifying a logged-in user.

Anywho, if you want to try this, don’t forget to implement some sort of Javascript or JQuery to make the flash message goes away for how many seconds you want this to happen, OK? Hopefully, this little trick will be of use for you as it is for me. Thanks for reading.

Was Our Universe Instantiated From A Superclass Universe?

If my memory isn’t too disconnected, then quantum mechanics — to how I remember best — is a science describing the smallest of the smallest matters and realms in which everyday physics rules do not apply. Quantum mechanics would try to explain the inner working mechanism of the smallest realm that forms particles that are even smaller than electrons – and these particles form electrons and other similar matters. To this day, the inner working mechanism of the quantum realm isn’t so clear, and so scientists sometimes can’t explain such as why one particle can appear to be at two different places at the same time. Theoretically, scientists like to think every matter in the universe is a wave of some sort, and this wave of some sort allows any matter to appear to be in multiple places at once.

To be honest, I don’t think we are too sure about all of this. In fact, I believe that some inner working mechanism of the universe would forever be hidden away from the human mind. Why? To explain this question in my own words, I like to allure you to the idea of object-oriented programming. In programming, languages such as Python use the concept of OOP to allow any programmer to be able to use new features from a class to enhance a programming project he or she is working on — but the programmer doesn’t necessarily need to know all the details of the class or how it was formed. In most cases, a programmer could import packages that got multiple classes and methods into a program he or she is working on, and then access the package’s class to create a new object in his or her image through cherry-picking some features from the package or package’s class — or just creating brand new features for the object through writing new functions and so forth. An example would be a programmer would import Flask into a program to allow the program to serve HTML/CSS/Javascript pages easily — in this case, the program doesn’t need an external web server such as Apache or whatever.

So, I imagine, you could too, that quantum mechanics could be like mechanics that allow our universe to import features from a superclass universe in which the inner working mechanisms of these features won’t be revealed to the human mind since the human mind is boxed inside this universe. Perhaps by chance, the superclass universe is generous that it would allow a mechanism to allow the quantum mechanics to reveal the thread back to itself, but to find out this truth I surmise it won’t be easy. Regardless, it’s not so hard for any of us to imagine this universe of ours is an object which could have been born from a superclass object like how a programmer could create a new object from a superclass without knowing how the superclass was created. If this is true, we could easily tempt to believe that this universe of ours is just one object among many hundreds of billions of similar objects out there that were also instantiated from the superclass universe.