Injecting the Cache Service

Hi Roy!

Ah, this is SUCH a great error. It's really hard to spot the problem the first time (the error from PHP is not that clear). You DID remember to add the use statement for Cache in MarkdownTransformer (forgetting this is the MOST common mistake). But, you have the wrong class. There are multiple classes from different libraries called cache. You want:

use Doctrine\Common\Cache\Cache;

If you look closely, the error says: "Hey, I'm you this ArrayCache object when MarkdownTransformer is instantiated. But, the type-hint on the argument says that you're expecting this other Sensio\Bundle\FrameworkBundle\Configuration\Cache object. That's a problem!".

Cheers!

Yeah I thought it had to be something similar to that. Got it working now, thanks :-)

I get this same error and I am using

use Doctrine\Common\Cache\Cache;

CRITICAL - Uncaught PHP Exception
Symfony\Component\Debug\Exception\ContextErrorException: "Notice:
Undefined property: AppBundle\Service\MarkdownTransformer::$cache" at
/home/rob/aqua_note/src/AppBundle/Service/MarkdownTransformer.php line
22

Solved it now though.

Hey robspijkerman ,

Glad you solved it! Was it a user error? Or do we have this error in code we provide to you?

Cheers!

Hey Eduardo Guglielmotti!

Ah, that's great news that any errors have been minor. Missing the use statement is probably the #1 thing that people forget. You'll make this mistake a few hundred times... then stop making it ;). As long as you can locate the problem, it's no issue.

About the strtoupper, it's ok! This should not be in your code anymore. We originally put this code in the MarkdownTransformer.parse() method, just so we could see things working. But then, we removed it and instead started using the MarkdownParser internally. You can see that at the very beginning of this video: https://knpuniversity.com/screencast/symfony-services/the-dreaded-dependency-injection. So, you're ok! Your fun fact should not be upper cased, but it should be running through markdown transformation.

Cheers!

Hey Terry,

Check my example how to inject templating service into your service:

#in services.yml

services:
    my_service:
        class: AppBundle\Service\MyService
        arguments: ['@templating']

# and then in MyService.php

namespace AppBundle\Service;

use Symfony\Bundle\FrameworkBundle\Templating\EngineInterface;

class MyService
{
    private $templating;

    public function __construct(EngineInterface $templating)
    {
        $this->templating = $templating;
    }

    public function someMethod()
    {
        $someVar = 'some-val';

        return $this->templating->render('path/to/template.html.twig', [
            'someVar' => $someVar,
        ]);
    }
}

So as you see injecting a service is very simple. Also if you use PhpStorm with configured Symfony plugin or actually any other good IDE - you will have an autocompletion for methods, so will see all methods which the EngineInterface interface has.

But if you mean outputting something in services with echo/print PHP statements - it's a bad practice. You probably need a custom Twig function or filter, check <a href="http://symfony.com/doc/current/templating/twig_extension.html&quot;&gt;How to Write a custom Twig Extension</a>. We also have a few screencasts about custom Twig extensions, check it out:
https://knpuniversity.com/screencast/symfony2-ep3/twig-extension-listener
https://knpuniversity.com/screencast/symfony-services/create-twig-extension

Cheers!

That's exactly what I needed. I was struggling to find the EngineInterface connection. Thanks much!

Figured it out... needed to use:
$this->renderResponse
instead of
$this->render
in my service.

I remembered one of the videos where Ryan dove into the controller and "render" was just a pass through method.

I'm having issues... As you have above the method someMethod in MyService returns the $this->templating->render(...) to my controller which is called like this:

    /**
     * @Route("/myapp")
     */
    public function myappAction()
    {
         $MyService= $this->get('app.MyService');
         return $MyService->someMethod();
    }

I was expecting the returns to bubble through back to the controller with the response object. But when I run the app, I'm getting the error message "The controller must return a response (<html><body>...".

It looks like its returning the raw html?!

Here is a screen shot:
https://s16.postimg.org/4g34v3jb9/Screenshot_1.png

ps
FYI: I'd like to attache a screenshot of the error, but it appears as though the ability to add images is turned off.

Hi Terry,

Yes, you're right. This method returns a raw HTML, but Controller::render() method returns a Response object, check it in source code to understand how it works behind the scene: https://github.com/symfony/... . To get a raw HTML is useful for rendering a mail body which you will send to user, etc.

Cheers

Hey Mehmet Eren Soylu!

I think I know the problem: it's due to a big "philosophical" change that we made in Symfony 3.3, and we need to add some notes to our tutorials to help guide people through them. Basically, add public: true to your service. Like this:

services:
    app.markdown_transformer:
        class: ...
        arguments: [...]
        public: true

While you're going through the tutorial, add that to any services that you create. Then, when you're ready, here is an explanation (actually written by me, so hopefully it makes some sense!) of how we've started configuring services slightly differently in Symfony 3.3: https://symfony.com/doc/current/service_container/3.3-di-changes.html

Cheers!

Thanks Ryan, cheers!

Hey Mike P.!

That's kind of weird, "bin/console cache:clear --env=prod" should do the work, if you make more changes to it, can you see them after clearing cache, or you have to delete the cache folder manually?

How did you customize the 404 page ?

Cheers!

Ive tried it again, now even with admin right:

pwd -> in correct directory (phpstorm)
Visit 404 page and Homepage
change /app/Resources/TwigBundle/views/Exception/error404.html.twig & views/main/homepage.html.twig (for start page)
run:
sudo ./bin/console cache:clear --env=prod && sudo ./bin/console cache:clear --env=dev
Got: [OK] Cache for the "prod" environment (debug=false) was successfully cleared.
[OK] Cache for the "dev" environment (debug=true) was successfully cleared.

But nothing changed on the site. After manually deleting the cache it works. Very strange.

Wow, this is a mystery! The bin/console cache:clear --env=prod command actually creates a fresh, new var/cache/prod directory, then deletes the old one, and moves this new one into its place (it's temporarily called pro_ if you look quickly). In other words, the cache directory is completely replaced when you run the command.

If you're curious, you could look for the cached Twig file and see what's inside. The Twig files cache down to PHP files, in var/cache/prod/twig There are a bunch of different directories and files, so you would need to grep in there for some content that appears on your 404 page. What would be interesting is to see - after you run cache:clear - is the correct, updated code inside the cached Twig template PHP file? Or does the cached Twig template PHP file still show the old code?

This is a long way of saying... this is weird.! It certainly should not work like this, and I can't think why it is!

Cheers!

That's something you can't miss when watching our tutorials ;)

Have a nice day!

Yo sdewijs!

Wooooh. Indeed, something is NOT right here (good idea to re-run composer install and also try a fresh composer update). I *do* think we have some problem, somehow, with either our dependencies, or something else weird. What's interesting is that those 2 classes are new in Symfony 3.2. So, it's almost like your container was cached when those files DID exist... but then your vendor directory got re-set to an old version. Some things to try:

A) Put your original composer.lock file back (if you still have it - otherwise download the code from this page and use ours)
B) Run an rm -rf vendor/ to completely reset things
C) Try a composer install
... if the problem persist
D) Run an rm -rf var/cache/* and then try re-building the cache

If (D) works, then - at least from a very high level - the issue is that your cached container got compiled using Symfony 3.2 (or later) code (somehow), but then your vendor directory (somehow) was changed to only include Symfony 3.1. Rebuilding the cache *uses* the existing cache. And in this situation, your existing cache would kind of be in a "poisoned state".

Phew! Ok, let me know what (if anything) works!

Cheers!

Thanks! I needed to perform all the steps from A to D to fix the problem. Not sure about the source of the issue though. Was coding along form lesson 1 and I haven't looked in production until this step so It could have existed for a while. Thanks again for the help and creating this awesome course!

Great news! Cheers!

Debug is ongoing here.... using PhP Storms search function, I searched for any instance of the text "my_markdown_cache" in my project. Only one.... in services.yml.... the very line we just typed.

This is interesting as this means that I have probably inadvertently damaged/deleted wherever it was that I built my_markdown_cache.

Now what tutorial step did we do that???? Time to go hunting....

ok... so I'm getting there... I finally spotted your notes about Symfony 3.3 and stripped the new lines from services.yml

Now, things seem to be working again.

Fingers crossed for the next parts.

Yo Rich Wilx!

Good debugging :). We're in a weird spot right now while we transition from the old, more manual way of defining services to the newer, autowiring way. In this tutorial, we use a version of Symfony that does not come with any of the new autowiring features - so you were correct to disable those (if you want to follow along with the tutorial exactly). Later this year, we'll start releasing tutorials that use the new autowiring way of doing things (once Symfony 4 comes out, in Nov). We have a tutorial about this new stuff (https://knpuniversity.com/s..., but mostly, it's not a huge change... it mostly makes life easier. So, keep on as you are, then watch for tutorials with the new stuff once Symfony 4 is here!

Cheers!

Hey Ryan....

Gotta say, I'm very fragile right now.... I'm just beginning to get the hang of Symfony 3.3 and now you speak of a major version coming out in just a few weeks.

How bad is it going to be for me if I decide not to jump up to the new shiny goodness when it arrives?

-Rich

Hey Rich!

Haha, oh no! It's really not going to be bad. In fact, this is one of the best reasons to use Symfony: we don't break backwards compatibility and we practice something called the "continuous upgrade path": a system where you can migrate your code across major versions without breaking things. We'll have a tutorial out in about 2 months about upgrading to Symfony 4.

In fact, usually, when big things happen in Symfony, it's not a change to the core code, but new recommendations we make about how you should write your code. That's more or less what's happening with Symfony 4. So, let me assure you, it's going to be ok! And here's my recommendation: continue with these tutorials, completing following them in the Symfony 3 way of doing things (so, commenting-out all the autowiring stuff as you did). When Symfony 4 comes out, we will have a tutorial about learning the changes. But, it's not as much as you think, and there are basically 2 big changes

A) The directory structure of a project will change. No big deal, you will have basically the same files, but in new locations.

B) We will use autowiring everywhere. The Symfony 3 way of doing things is to wire all of your services in services.yml manually. In Symfony 4, much of this will be automated, but everything under the hood is still the same (in fact, the manual wiring will still work, if you prefer that way). So, the change from Symfony 3 to Symfony 4 will be to do less work, and let the framework take care of more tasks for you. You're actually in great shape, because you're learning it the "hard" way. In Symfony 4, you'll need to worry about less. I think it's a bit like driving a car: you're learning to drive a manual transmission now. In Symfony 4, it's an automatic transmission. It will (hopefully) be so much simpler, you'll get bored ;).

So, keep going! And we'll help you through the Symfony 4 changes when it's time. You're doing great! I know because of how well you debugged this issue.

Cheers!