mkdocs-material: PHP highlighting only works when code block begins with Description
I’m able to achieve good code highlighting in PHP code, but only when the code begins with <?php
. I would like a way to highlight PHP code without having to insert anything into the code block that will display within in the presented code.
When using <?php
```
<?php
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```

This highlighting is good, but I don’t want to insert <?php
into all of my php code blocks because (1) it clutters the final presentation, and (2) will confuse some users who think they need to actually write <?php
in the example being documented, and (3) is just a tiny bit more work to type.
When using ```php
I would prefer to write my code blocks as follows:
```php
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```
but using the ```php
syntax hint does not seem to take affect. With this markdown, I see no code highlighting at all.

Without any language hints
If I don’t mention PHP, I get some highlighting, but it’s done so poorly that it’s actually worse than no highlighting at all.
```
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```

Other notes
- With the three examples above, I see different markup for each, when inspecting with a browser inspector. (e.g. all elements have
class="x"
in example that produces no highlighting)
- PHP code highlighting works for me in the
readthedocs
theme by using ```php
- Language hinting seems to work well within Material for other languages when I do
```js
or ```python
, but not PHP.
- I’ve read #41 and #30 but this seems to be a separate issue
Package versions
- Python:
python --version
2.7.6
- MkDocs:
mkdocs --version
0.16.1
- Material:
pip show mkdocs-material | grep -E ^Version
1.0.3
- Pygments:
pip show pygments | grep -E ^Version
2.2.0
Project configuration
site_name: Foo
theme: material
markdown_extensions:
- codehilite
pages:
- Home: index.md
I’ve also tried - codehilite(css_class=code)
(as recommended in other issues I read) but that produced no highlighting at all.
System information
- OS: Linux Mint
- Browser: Firefox & Chrome
Description
I’m able to achieve good code highlighting in PHP code, but only when the code begins with <?php
. I would like a way to highlight PHP code without having to insert anything into the code block that will display within in the presented code.
When using <?php
```
<?php
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```
This highlighting is good, but I don’t want to insert <?php
into all of my php code blocks because (1) it clutters the final presentation, and (2) will confuse some users who think they need to actually write <?php
in the example being documented, and (3) is just a tiny bit more work to type.
When using ```php
I would prefer to write my code blocks as follows:
```php
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```
but using the ```php
syntax hint does not seem to take affect. With this markdown, I see no code highlighting at all.
Without any language hints
If I don’t mention PHP, I get some highlighting, but it’s done so poorly that it’s actually worse than no highlighting at all.
```
$a = array("foo" => 0, "bar" => 1);
foreach ($a as $key => $value) {
// comment
echo "{$key} => {$value}" . PHP_EOL;
}
```
Other notes
- With the three examples above, I see different markup for each, when inspecting with a browser inspector. (e.g. all elements have
class="x"
in example that produces no highlighting) - PHP code highlighting works for me in the
readthedocs
theme by using```php
- Language hinting seems to work well within Material for other languages when I do
```js
or```python
, but not PHP. - I’ve read #41 and #30 but this seems to be a separate issue
Package versions
- Python:
python --version
2.7.6 - MkDocs:
mkdocs --version
0.16.1 - Material:
pip show mkdocs-material | grep -E ^Version
1.0.3 - Pygments:
pip show pygments | grep -E ^Version
2.2.0
Project configuration
site_name: Foo
theme: material
markdown_extensions:
- codehilite
pages:
- Home: index.md
I’ve also tried - codehilite(css_class=code)
(as recommended in other issues I read) but that produced no highlighting at all.
System information
- OS: Linux Mint
- Browser: Firefox & Chrome
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 32 (28 by maintainers)
This may be something I could implement in
pymdown-extensions
. Maybe allow a user to specify a new language aliases likephp-inline
and give it the translationphp
and the optionsstartinline=True
. Essentially you could extend the current language list with a pre-configured language variants.Maybe I’ll implement this. I might actually get some use out of something like this.
FYI 2.0 is released. Documentation on the Highlight extension that contains this feature is here: http://facelessuser.github.io/pymdown-extensions/extensions/highlight/. Please file issues or ask questions over at https://github.com/facelessuser/pymdown-extensions/issues if you encounter problems.
FYI, the final form of this might actually change even though I wasn’t planning it. I am looking to generally decouple pymdown highlighting from CodeHilite as I am potentially going to expose more Pygments settings and we will deviate even more from CodeHilite. But by default, SuperFences and InlineHilite will still source settings from CodeHilite and provide only features that CodeHilite provides.
I am thinking about creating an extension that configures highlighting globally for pymdown extensions instead of having some settings shared in a confusing manner. So if sourcing settings from CodeHilite was disabled for the SuperFences and/or InlineHilite, those extensions would instead utilize this new extension allowing them to take advantage of more advanced features. And they could all be tweaked in one place instead of having two different extensions that can configure them separately, but work globally.
Anyways, nothing is certain, but I want people to be aware that this might possibly be more different than what is outlined here.
So in general, legacy behavior would mostly be preserved and affect very few people. This would most likely be part of a
2.0
release as this would be a significant change. I will leave the current branch I mentioned here untouched and probably create a new branch with the final feature.I would advise just following https://github.com/facelessuser/pymdown-extensions/issues/54 for further developments. I am open to suggestions as I try and iron all this out.