21

If you have devMode set to "true" in your config files, you can use "dump" in a twig template like this without any plug in needed: {{ dump(myArray) }}


13

There's the dbug plugin which should give you what you are after, template side. This plugin adds a helpful dbug method to your Craft templates. This will help you see in the dark - figure out what kind of variables you are dealing with, and what methods they implement.


10

So this sounded like a fun problem to solve... so I wrote the Template Comments plugin that does what you want: This free plugin adds a HTML comment to demarcate {% block %}s and each Twig template that is included or extended.


9

There are two checkboxes in your user settings, go to your admin account -> preferences index.php?p=admin/myaccount and check the boxes This is covered in detail in the Profiling your Website with Craft CMS 3’s Debug Toolbar article


7

There's a plugin called "craft inspector" https://github.com/adrianmacneil/craft-inspector that has come in handy. {{ craft.request | inspect }} {{ inspect(craft.request) }}


6

The dump tag is not a logic operator (e.g., no percent sign) — it should use the simple field brackets. As well, the proper format is either .url or .getUrl() {{ dump(craft.request.url) }}


5

For anyone finding it annoying having to be authenticated to enable the debug bar, particularly when testing in multiple browsers, it’s easy to override this behaviour with a custom module. Just add the following to your init() code: // In dev envs override user debug toolbar prefs based on devMode setting if (getenv('ENVIRONMENT') === 'dev' && ! ...


5

Craft 3 If you enabled the debug toolbar in the user profile, but it still does not show on the frontend, AND you are running Craft not locally but on a different host (different IP), try adding this to your config/app.php: 'local' => [ 'bootstrap' => ['debug'], 'modules' => [ 'debug' => [ 'class' => 'yii\debug\...


5

Twig's dump tag is only available when Craft's devMode is enabled.


4

There already was a warning about it, but it didn’t really stick out, I guess. Just gave it the actual Warning style treatment, so hopefully this helps the next guy:


3

The behaviour you're seeing is by design – craft.request.getQuery() will return all GET variables if it's called without arguments, whereas craft.request.getParam() requires the name argument – i.e. craft.request.getParam('foo'). The changelog notes for build 1.3.2465 does reference a couple of issues related to these methods, but nothing suggesting any ...


3

Stick {{ dump(_context) }} in a template file to print out all the available values. {{ dump(_context|keys) }} Outputs the keys of the array without going through it recursively.


3

I was only able to answer this because the OP sent a support ticket to and was able to look at their database. :) When the site was setup in Craft Pro trial mode, the content was built out with multiple locales and those locales were enabled for the sections. Craft Personal only allows for 1 locale, so when you try to save an entry in a section that was ...


3

I point File->Open Directory at craft/.., and PhpStorm pick up everything for me. You probably have to set up path mappings to make debugging work properly, but PhpStorm will alert you to that and launch the mapping UI. I have a sandbox Craft install running at local.sandbox.dev and I create a git repo in the plugins directory, and develop the plugin in ...


3

Just had a similar issue with a colleague. Double check your folder permissions. It might be the case that Craft isn’t allowed to write the transformed files to your assets folder. Something like chmod -R 777 public/assets might do the trick. (You might want set this to something other than 777 if it worked out. Look at the docs for details.)


3

I had a similar problem with disappearing fields in the admin interface, and found it seemed to be something to do with the xdebug PHP extension. Disabling that fixed the problem and the fields reappeared: sudo php5dismod xdebug sudo service apache2 restart The problem in this case is actually to do with reaching a nesting limit, so if you do want to use ...


3

Making it only available to logged in users and/or admin, would make it impossible to debug the site as an anonymous user would see it. I'd say that's an pretty important feature which I think is wrong to remove just because someone might configure craft wrong. But maybe it'd be possible to use a plugin to turn on/off devMode depending on user permissions?


2

I can confirm that Win8.1 + PHPStorm + xDebug and plugin code works fine. Are you symlink'ing (using mklink in Windows) to your plugin code by chance? xDebug won't follow symlink's by default and at least in PHPStorm, you have to explicitly setup the path mapping in your project's settings to tell PHPStorm/xDebug where the actual paths to your symlink'ed ...


2

Try to set the siteUrl in config/general.php like so. return array( '*' => array( ), 'localhost' => array( 'siteUrl' => 'http://localhost:3001/', ), ); And then apply your replace filter. <span>{{ siteUrl|replace({'localhost:3001': 'mysite.com'}) }}</span>


2

Unknown error messages in the control panel almost always happen over an AJAX request and are usually 500 response code Internal Server Errors, so there isn't an convenient way to display a meaningful error message with a full stack trace to help debug. But you've found the next best thing... the error logs in craft/storage/runtime/logs. Usually if you ...


2

I'm guessing you're on MediaTemple? http://buildwithcraft.com/help/forms-returning-json


2

To anyone wondering, it had to do with the PHP memory limit and max_post_size. If you're coming across this error, increase the limit.


2

I'm not sure this is the proper way to do it but I got this working. I used the Yii\Application::EVENT_BEFORE_REQUEST event in my plugin's init() method: <?php namespace my\namespace; use craft\base\Plugin; use craft\web\Application; class MyPlugin extends Plugin { public function init() { Event::on( Application::class, ...


2

The usual method for debugging a Craft site is to pull down a copy of the production database content, import it into your local development database and run a local copy of the site's code on your computer. You can run the site using Craft's Nitro development environment, or use other local development environment frameworks like Valet or MAMP. Once you ...


1

The reason for the discount not being applied is that nearly all your products have not been marked as promotable (by looking at your database): Screenshot: http://jmp.sh/3FAK6NH No sales or discounts can be applied to a non-promotable product.


1

On a multi-site setup, you need to use the multi-site array syntax for the siteUrl config setting like so: 'siteUrl' => [ 'siteHandle1' => 'https://foo.com/', 'siteHandle2' => 'https://bar.com/', ],


1

The error you're showing from the logs is a simple 404 error that occurs whenever someone or something requests a URI on your site that doesn't resolve to anything. In this case it is /(X(1)S(q325ycazg05lq11ktn1hqjtx))/copyright, which is likely a script probing for vulnerabilities, which is very common for any public website. We've moved those 404 ...


1

Not a direct answer to your question, but I keep a pretty up to date Nginx config for Craft here: Nginx-Craft that may be useful to you at some point. Glad you got it sorted.


1

It appears nginx is setup correctly. In Craft, your Assets URL can be different than your assets path, which I think is where some confusion is coming in. If Craft's file upload path is outside nginx root (otherwise known as the DocumentRoot directive in Apache), you could either move your asset storage so it's under the document root—and thus "public" or "...


1

Right! setting the mapping to the specific file, in this case the controller of plugin made it all work. Thanks again for taking the time!


Only top voted, non community-wiki answers of a minimum length are eligible