primordic/IssueDupesLite huggingface dataset:
Repository: phpDocumentor/phpDocumentor

Issue #488: Parsing error :  PHPParser_Node_Const could not be converted to string
Created: 2012-06-06T08:54:52Z
I got with new alpha5 version :
PHP Catchable fatal error:  Object of class PHPParser_Node_Const could not be converted to string in /usr/share/php/phpDocumentor/src/phpDocumentor/Reflection/BaseReflector.php on line 168
In fact, this can be reproduce with a simple define on a simple file :
<?php

$name = 'ONE';
// crash because of $name
define("BOOM_$name", true);

?>

Duplicate issue #496: Fatal error in PHPParser_Node_Const  parsing sources
Created: 2012-06-14T05:33:06Z
While parsing source of SugarCRM, got this fatal error:
Catchable fatal error: Object of class PHPParser_Node_Const could not be converted to string in /Applications/MAMP/bin/php5.3/lib/php/phpDocumentor/src/phpDocumentor/Reflection/BaseReflector.php on line 168
Unfortunately, I don't see how to extract more info to see what exactly in what file throws it off.

Closing comment (2012-06-16T16:35:04Z): Sounds like a duplicate of #488.
Repository: phpDocumentor/phpDocumentor

Issue #1838: Block diagram feature
Created: 2017-04-21T12:45:43Z
Some parts of complex projects need to be documented in block diagrams. It would be great if phpDocumentor had such feature.
So, if we document code like this...
/* @block-diaram start */

/* @block-diaram action Prepare storage */
Storage::prepare();
/* @block-diaram action end */

/* @block-diaram condition start Is user active? */
if (User::active) {
    /* @block-diaram condition yes */
    /* @block-diaram action Get data */
    User::getData();
    /* @block-diaram action end */
    /* @block-diaram action Success message */
    Message::ok();
    /* @block-diaram action end */
} else {
    /* @block-diaram condition no */
    /* @block-diaram action Error message */
    Message::error();
    /* @block-diaram action end */
}
/* @block-diaram condition end */

/* @block-diaram end */

... we'll get an image in report.

I hope you understand this idea.

Duplicate issue #3359: i want to use UML Graph
Created: 2022-11-10T14:20:19Z
/**
 * Renders a uml diagram, example:
 *
 * .. uml::
 *    skinparam activityBorderColor #516f42
 *    skinparam activityBackgroundColor #a3dc7f
 *    skinparam shadowing false
 *
 *    start
 *    :Boot the application;
 *    :Parse files into an AST;
 *    :Transform AST into artifacts;
 *    stop
 */

I am using it in this way, but the output of the same text is displayed
Feature request

Closing comment (2023-09-10T09:43:53Z): This looks to me similar to #1838 - and should be probably implemented (by whoever decides to take up the challenge and create a PR) following the ideas outlined there.
Repository: phpDocumentor/phpDocumentor

Issue #74: Show methods from superclasses
Created: 2011-04-21T09:24:55Z
Only methods from the current class are shown; but it would be super if the methods from superclasses would be shown and those open the superclass' page.

Duplicate issue #175: Show inherited methods
Created: 2011-07-25T14:03:17Z
It would be great if generated documentation could show also inherited methods from parent class (chain).

Closing comment (2011-07-25T20:54:47Z): Thanks for your issue report. Unfortunately this is a duplicate of #74, fortunately that means it will certainly implemented ;)
Repository: phpDocumentor/phpDocumentor

Issue #74: Show methods from superclasses
Created: 2011-04-21T09:24:55Z
Only methods from the current class are shown; but it would be super if the methods from superclasses would be shown and those open the superclass' page.

Duplicate issue #208: inheritDoc and automatically inheriting doc not working in 0.13 - regression?
Created: 2011-08-15T14:38:14Z
i think i stumbled over a regression with 0.13 against 0.12: using {@inheritdoc} stopped working, and if i have an empty doc bloc, doc is no longer taken from parent class / implemented interface. with 0.12 it works fine, on exactly the same code...

Closing comment (2011-08-15T20:23:28Z): I believe this to be similar to the issue reported in #74 as they share a similar codebase; will investigate this and fix as soon as possible.
Thanks for reporting!
Repository: phpDocumentor/phpDocumentor

Issue #1950: Docker image instructions do not work
Created: 2018-01-31T04:30:13Z
The instructions about pulling the docker image does not work
Expected Behavior

docker pull phpdoc/phpdoc works
Actual Behavior

docker pull phpdoc/phpdoc does not work because there is no latest tag in docker hub.
Steps to Reproduce the Problem

Run docker pull phpdoc/phpdoc

Duplicate issue #1967: No latest tag on docker repo
Created: 2018-03-22T16:21:01Z
FYI the readme instructions for docker don't work as there is no latest tag available on https://hub.docker.com/r/phpdoc/phpdoc/tags/

Closing comment (2018-04-20T09:51:25Z): closing this because it duplicates #1950
Repository: phpDocumentor/phpDocumentor

Issue #38: Implement mechanism to find common folder
Created: 2011-04-10T12:27:47Z
With Docblox it is possible to mix and match multiple directories (-d) and files (f).
Now we take the folder of the first -d option to extract the 'base' folder; which is cut from the filenames.
This mechanism is to 'simple' and should be replaced with a mechanism which finds the highest folder that every file and directory have in common and use that as basis.

Duplicate issue #70: Parsing multiple directories breaks the parser
Created: 2011-04-20T13:00:49Z
C:\wamp\bin\php\php5.3.1>php.exe "C:\docblox\bin\docblox.php" project:run -d "C:\test\test2,C:\test\test" -t "C:\output" --force -v

One would expect to find that both directories are parsed, and the verbose output (see bottom) shows us that they are. But instead of the usual html documents (one per file) all it creates is an empty(0 bytes) file called "C". In the index it creates links to the files its expecting that look like this:
<a href="C:_test_test2_test.html#Test">Test</a>

Which should look like this (this is after parsing the parent dir of both subdirs)
<a class="" href="test2_test.html#Test">Test</a>

I figure somewhere a replace operation on the \ is breaking on something. Maybe wrong syntax in the --directory parameter? However, that same syntax does work when using --ignore on multiple directories
verbose output:
2011-04-20T12:51:21+00:00 INFO (6): [2.25mb]: Starting to process 4 files
2011-04-20T12:51:21+00:00 INFO (6): [2.26mb]: Starting to parse file: C:\test\test2\newtest.php
2011-04-20T12:51:21+00:00 INFO (6): [2.92mb]: Starting to parse file: C:\test\test2\test.php
2011-04-20T12:51:21+00:00 INFO (6): [2.98mb]: Starting to parse file: C:\test\test\newtest.php
2011-04-20T12:51:21+00:00 INFO (6): [2.98mb]: Starting to parse file: C:\test\test\test.php
2011-04-20T12:51:21+00:00 INFO (6): [3.29mb]: Processing the file: C:\test\test2\newtest.php as C:\output\C:_test_test2_newtest.html
2011-04-20T12:51:21+00:00 INFO (6): [3.29mb]: Processing the file: C:\test\test2\test.php as C:\output\C:_test_test2_test.html
2011-04-20T12:51:21+00:00 INFO (6): [3.29mb]: Processing the file: C:\test\test\newtest.php as C:\output\C:_test_test_newtest.html
2011-04-20T12:51:21+00:00 INFO (6): [3.29mb]: Processing the file: C:\test\test\test.php as C:\output\C:_test_test_test.html

Closing comment (2011-04-22T20:59:04Z): This issue is related to #38 and will be fixed as part of it; this issue will remain open to remind me to check this once done
Repository: phpDocumentor/phpDocumentor

Issue #2820: @var ignores the description section
Created: 2021-02-12T16:30:05Z
When using the @var tag and providing a description for the tag, the generator ignores the description entirely
Expected behavior
/** @var string|null Short docblock, should contain a description. */
protected $description = null;
Should produce something like this:
$description : string|null Short docblock, should contain a description.
Actual behavior
The document only shows:
$description : string|null
Steps to reproduce the problem

As the documentation example tag a constant or property of a class with the '@var' tag
/** @var string|null Short docblock, should contain a description. */
protected $description = null;
Generate the documentation
Confirm result in documentation page

Your environment


Version used: 3.0.0-alpha1
Install method: PHAR file
PHP version: 7.4.15
Operating system and version (e.g. Ubuntu 20.04, Windows 10): Windows 10
Link to your project:
Attach code that is involved
...

Duplicate issue #2808: @var handling does not work without element name
Created: 2021-02-05T23:35:19Z
The Tag Reference for the @var tag says:

The @var tag MUST contain the name of the element it documents. An exception to this is when a declaration only refers to a single property or constant. In that case, the name of the property or constant MAY be omitted.

The latter seems not to work. Here's a simple class with a single property and a doc block as auto-completed by PHPStorm:
<?php

class Test {

    /** @var int This text should be shown */
    public $test = 5;
}
This is the result (using the latest available .phar as of today):

Expected behavior
I would expect the descriptive text for the test property "This text should be shown" to be visible in the docs.
Actual behavior
No text is available for the property.
Steps to reproduce the problem

create a test.php file with the above contents
run php7 phpDocumentor.phar -f test.php -t docs

Environment

Version used: v3.0.0
Install method: phar
PHP version: 7.4.15
Operating system and version: Arch Linux

Closing comment (2021-04-23T15:54:15Z): I think this is a duplicate of #2820 Will check this with some tests.
Repository: pi-hole/pi-hole

Issue #6055: v6 command line query option error
Created: 2025-03-06T19:05:17Z
Versions


Core version is v6.0.5 (Latest: v6.0.5)
Web version is v6.0.2 (Latest: v6.0.2)
FTL version is v6.0.4 (Latest: v6.0.4)

Platform


OS and version:  Ubuntu 24.10 (6.11.0-19-generic)



Platform:  Dell

Expected behavior
The following query command should show which rule matches the query argument when there is a regex deny filter like (^|\.)omtrdc\.net$ is setup under Domain management tab.
$ pihole -q www.omtrdc.net
Actual behavior / bug
The above command results in the following error
# pihole -q www.omtrdc.net
jq: parse error: Invalid escape at line 1, column 52
jq: parse error: Invalid escape at line 1, column 52
Found  domains exactly matching 'www.omtrdc.net'.

/opt/pihole/query.sh: 65: [: Illegal number: 
Found  adlists exactly matching 'www.omtrdc.net'.

/opt/pihole/query.sh: 78: [: Illegal number: 
/opt/pihole/query.sh: 117: [: Illegal number: 

Steps to reproduce
Steps to reproduce the behavior:

setup a regex deny filter (^|\.)omtrdc\.net$ under Domain management tab
run the command pihole -q www.omtrdc.net

Debug Token

URL:  N/A


Screenshots
N/A
Additional context
N/A

Duplicate issue #6077: Manually disabling/enabling blocking seems broken in v6
Created: 2025-03-10T17:52:51Z
Versions

Core version is v6.0.5 (Latest: v6.0.5)
Web version is v6.0.2 (Latest: v6.0.2)
FTL version is v6.0.4 (Latest: v6.0.4)
Platform
Raspbian GNU/Linux 12 (bookworm)
Pi-hole installation bare-metal, with unbound without any tweak. Working as a charm for years (Thank you, you rock!)
Expected behavior
Just upgraded from v5 to v6 this morning. The update was smooth and took 2 minutes. Great job!
I have some adlists and a few deny regex
Example (\.|^)web\.webex\.com$
Actual behavior / bug
When disabling blocking via the menu (for 5 minutes or whatever), https://web.webex.com is accessible, which is OK
Then, re-enable blocking manually via the menu, https://web.webex.com is still accessible.
Observed in browser, with cache flushed, private navigation too, etc. Observed with curl too.
The only thing to make the website inaccessible again is to stop/start FTL by CLI
It seems to me that a cache flush is missing in this process of manual disable/enable. It worked instantly in v5, as I use this "feature" a lot to troubleshoot on my network. So I suspect something missing at this level.
Debug Token

URL:  https://tricorder.pi-hole.net/z1th9uI5/

Thanks!

Closing comment (2025-03-10T20:36:08Z): Might (or not) be related to #6055. Here is the output for me
$ sudo pihole -q web.webex.com
parse error: Invalid escape at line 1, column 56
parse error: Invalid escape at line 1, column 56
Found  domains exactly matching 'web.webex.com'.

/opt/pihole/query.sh: 65: [: Illegal number: 
Found  adlists exactly matching 'web.webex.com'.

/opt/pihole/query.sh: 78: [: Illegal number: 
/opt/pihole/query.sh: 117: [: Illegal number:
Repository: pi-hole/pi-hole

Issue #3947: Basic install logic doesn't parse Centos 8 Stream /etc/redhat-release text correctly.
Created: 2020-12-27T04:30:56Z
Versions


Pi-hole:  v5.2.2
AdminLTE:  v5.2.2
FTL:  v5.3.4

Platform

OS and version:
CentOS Stream release 8
Platform:
x86_64

Expected behavior
Installer should function or give an error.
Actual behavior / bug
Installer bails out without a message inside of the distro_check function.
It seems the regexp used to parse /etc/redhat-release to fill
CURRENT_CENTOS_VERSION is not working as expected.
manually setting the variable instead of using the rexgrep allows the install to continue.
What's really weird is that fallback error mesg logic isn't firing either.  Just seems to fail siliently because it can't parse /etc/redhat-release. No warning message about unsupported release.  So it took me a little bit to track down where in the install script it was failing by sprinkling printfs into the script.
Steps to reproduce

Prepare a Centos Stream 8 install with static IP
Follow the install instructions to using basic_install.sh
Watch installer fail without error message after displaying the ascii artwork

Steps to mitigate

comment out the CURRENT_CENTOS_VERSION=...   line in distro_check function
add CURRENT_CENTOS_VERSION=8

Additional context
It maybe easier to add logic to prefer to parse /etc/os-release if it exists on the system instead of redhat-release.  If /etc/os-release exists on the system, it will have an explicit VERSION key separate from name.

Duplicate issue #3983: Check for CentOS version crashes the installer for CentOS Stream 8
Created: 2021-01-12T09:53:55Z
Versions


Pi-hole version is v5.2.2 (Latest: v5.2.2)
AdminLTE version is v5.2.2 (Latest: v5.2.2)
FTL version is v5.3.4 (Latest: v5.3.4)

Platform

OS and version:  CentOS Stream 8
Platform:  Virtualbox on QNap

Expected behavior
installation to end with success or throw a meaningful error
Actual behavior / bug
The installation script crashes without comment, error or logfile entries
The reason is in this line: CURRENT_CENTOS_VERSION=$(grep -oP '(?<= )[0-9]+(?=\.)' /etc/redhat-release)
The version string on this version of linux is "CentOS Stream release 8"
Steps to reproduce

change your /etc/redhat-release to say CentOS Stream release 8
try any type of installer

Workaround
changing the above line to CURRENT_CENTOS_VERSION=8
Remark
Given that CentOS 8 is going away and CentOS stream is one of the succeeding distros, it would make sense to change this check to support this version as well.

Closing comment (2021-01-12T10:21:22Z): Thanks for the report. This is a duplicate of
#3947
Fix already in the pipeline.
Repository: pi-hole/pi-hole

Issue #4393: Add Almalinux Support
Created: 2021-10-17T03:44:16Z
Versions


Pi-hole:  v5.5
AdminLTE:  v5.7
FTL:  v5.10.2

Platform


OS and version:  AlmaLinux 8.4



Platform:  proxmox LXC container

Expected behavior
Install works with no extra flags since almalinux is 1:1 to compatible with RHEL/CentOS
Actual behavior / bug
In order for the install to work I had to run the installer the following command instead of just piping straight to bash. -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash
Steps to reproduce
Steps to reproduce the behavior:

run curl -sSL https://install.pi-hole.net | sudo bash
receive  this error message Unsupported OS detected: Almalinux 8.4
If you are seeing this message and you do have a supported OS, please contact support.
run curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash and the install completes as expected

Debug Token

URL:  https://tricorder.pi-hole.net/PoK2UimG/


I will submit a pull request to update the script and try on rockylinux and centos stream if time allows

Duplicate issue #4391: Install script doesn't work on AlmaLinux
Created: 2021-10-16T14:51:40Z
Versions


Pi-hole:  v5.5
AdminLTE:  v5.7
FTL:  v5.10.2

Platform


OS and version:  AlmaLinux 8.4



Platform:  proxmox LXC container

Expected behavior
Install works with no extra flags since almalinux is 1:1 to compatible with RHEL/CentOS
Actual behavior / bug
In order for the install to work I had to run the installer the following command instead of just piping straight to bash. -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash
Steps to reproduce
Steps to reproduce the behavior:

run curl -sSL https://install.pi-hole.net | sudo bash
receive  this error message Unsupported OS detected: Almalinux 8.4
If you are seeing this message and you do have a supported OS, please contact support.
run curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash and the install completes as expected

Debug Token

URL:  https://tricorder.pi-hole.net/PoK2UimG/


I will submit a pull request to update the script and try on rockylinux and centos stream if time allows

Closing comment (2022-01-08T12:41:49Z): Closing, as it is basically a duplicate of #4393
Repository: pi-hole/pi-hole

Issue #264: .js calls are not replaced by the Pi-hole html
Created: 2016-01-30T03:14:24Z
It looks like adverts that are served up by scripts are not replaced by the index.html provided by Pi-hole. In the below lighttpd/access.log snippet only the call to amazon-adsystem is replaced, the others are just rendered as blank spaceholders in the Chrome browser.
1454123251|rcm-na.amazon-adsystem.com|GET /e/cm?t=oxd-20&o=1&p=12&l=st1&mode=electronics&search=Apple&fc1=000000&lt1=_blank&lc1=3366FF&bg1=FFFFFF&f=ifr HTTP/1.1|200|153
1454123273|w.sharethis.com|GET /button/buttons.js HTTP/1.1|304|0
1454123273|tags.expo9.exponential.com|GET /tags/OSXDailycom/ROS/tags.js HTTP/1.1|304|0
1454123273|www.google-analytics.com|GET /urchin.js HTTP/1.1|304|0
1454123273|stats.wordpress.com|GET /e-201604.js HTTP/1.1|304|0
1454123273|rcm-na.amazon-adsystem.com|GET /e/cm?t=oxd-20&o=1&p=12&l=st1&mode=electronics&search=Apple&fc1=000000&lt1=_blank&lc1=3366FF&bg1=FFFFFF&f=ifr HTTP/1.1|304|0
1454123274|s3.buysellads.com|GET /ac/bsa.js HTTP/1.1|304|0
1454123328|stats.wp.com|GET /e-201604.js HTTP/1.1|200|153

Duplicate issue #241: Couchtuner Ads
Created: 2016-01-25T05:30:03Z
So often use couchtuner.ch . It looks like Pi-hole is replacing the ads quite nicely, including the ones that appear on top of the videos.
However there empty containers remain, which means I still have to close them to hit play. Is there any way to change the "z" or layer that the ad appears on, so that the video loads over top and they don't block the play button?
I don't know these languages (yet) but I'll give them a shot eventually. Just thought I'd ask.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Closing comment (2016-01-30T17:13:20Z): Related to #264?
Repository: pi-hole/pi-hole

Issue #4611: Flush Logs functionality not clearing logs
Created: 2022-02-13T10:11:27Z
Since updating to 5.9 the Flush Logs (Last 24 hours) button to not seem to clear any logs. Dashboard still report same quiries etc.

Duplicate issue #4627: Query Log can‘t be flushed
Created: 2022-02-21T11:14:09Z
Versions


Pi-hole:  v5.9
AdminLTE:  v5.11
FTL: v5.14
PADD: v3.6.6

Platform

OS and version:  raspbian OS Buster legacy
Platform:  RPi3+B and RPi0

Expected behavior
Flushed the 24h Query Log by pressing the relevant button under settings after confirmation from pihole.
Actual behavior / bug
Despite the fact the flaushing was confirmed from pihole, the data stays as the the button was never pressed.
This happens on two independen indtances on a RPi3+ and a RPi Zero the same way.
Steps to reproduce the behavior:

Go to 'setting'
Click on 'flush query log'
‚Wait for flush confirmation message from pihole'
‚Watch the dashboard and wonder why.‘

Closing comment (2022-02-21T11:16:19Z): Duplicate: #4611
Repository: pi-hole/pi-hole

Issue #5962: Configuration backup via pihole -a -t doesn't work
Created: 2025-02-22T08:04:52Z
Versions


Pi-hole: v6.0.3
AdminLTE: v6.0.1
FTL: v6.0.2

Platform


OS and version: raspi 6.1.21-v7+



Platform: native

Expected behavior
Configuration backup to current directory.
Actual behavior / bug
Teleporter is removed from CLI.
Steps to reproduce
Steps to reproduce the behavior:

run /usr/local/bin/pihole -a -t in shell

Additional context
After upgrading pihole from v5 to v6 I'm unable to run crontab backup.
Also, pihole binary now requires sudo. It did not required sudo on v5.

Duplicate issue #5967: pihole -a -t backup.tgz & pihole -a -r backup.tgz no longer create and restore backup files
Created: 2025-02-22T14:42:02Z
Versions


Pi-hole:  6.0.3
AdminLTE:  6.0.1
FTL:  6.0.2

Platform


OS and version:  Debian 12



Platform:  Raspberry Pi

Expected behavior
pihole -a -t backup.tgz
should generate a tgz of a backup and save it in backup.tgz
pihole -a -r backup.tgz
should restore a tgz of a backup from backup.tgz
Actual behavior / bug
Running those commands now just shows the Usage for the pihole command
Steps to reproduce
Steps to reproduce the behavior:
From a command prompt, run pihole -a -t backup.tgz or pihole -a -r backup.tgz
Debug Token

URL:

[✓] ** FINISHED DEBUGGING! **

The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.

[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (22) The requested URL returned error: 500
[✗] There was an error uploading your debug log.

Please try again or contact the Pi-hole team for assistance.
A local copy of the debug log can be found at: /var/log/pihole/pihole_debug.log

Screenshots
N/A
Additional context
I have a script I run weekly to generate a backup of my various pi-hole systems. I want to be able to automate backups. I don't mind doing restores from the web GUI, but I'd prefer the CLI.

Closing comment (2025-02-22T14:49:08Z): Duplicate of #5962
Repository: pi-hole/pi-hole

Issue #3790: Dashboard doesn't show queries
Created: 2020-10-09T15:25:37Z
Versions


Pi-hole:  5.1.2
AdminLTE:  5.1.1
FTL:  5.2

Platform


OS and version:  RaspberryPi OS



Platform:  Raspberry Pi,

Expected behavior
While browsing queries should be displayed on the dashboard
Actual behavior / bug
Looking at some websites it seems pihole is blocking ads, but the dashboard doesn't show anything.
Despite that, queries are logged when i run "pihole -d" in the console
Steps to reproduce
Steps to reproduce the behavior:

Fresh install of RaspberryPi OS with Pi Imager
Install pihole (everything as recommended)
Open Dashboard and visit websites

Debug Token

URL:  https://tricorder.pi-hole.net/vxvx4amnso


Screenshots
Additional context

Duplicate issue #3789: Dashboard doesn't show queries
Created: 2020-10-09T15:24:54Z
Versions


Pi-hole:  5.1.2
AdminLTE:  5.1.1
FTL:  5.2

Platform


OS and version:  RaspberryPi OS



Platform:  Raspberry Pi,

Expected behavior
While browsing queries should be displayed on the dashboard
A clear and concise description of what you expected to happen.
Actual behavior / bug
Looking at some websites it seems pihole is blocking ads, but the dashboard doesn't show anything.
Despite that, queries are logged when i run "pihole -d" in the console
A clear and concise description of what the bug is.
Steps to reproduce
Steps to reproduce the behavior:

Fresh install of RaspberryPi OS with Pi Imager
Install pihole (everything as recommended)
Open Dashboard and visit websites

Debug Token

URL:  https://tricorder.pi-hole.net/vxvx4amnso


Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Closing comment (2021-08-10T18:48:24Z): Duplicate of
#3790
Repository: pi-hole/pi-hole

Issue #5904: V6 "Building tree" need a lot more ram with huge amount of blocked domains than v5
Created: 2025-02-19T08:18:03Z
Pi-hole:  6
AdminLTE:  6
FTL:  6

Platform

OS and version:  Debian Bookworm
Platform:  Raspberry 3B+

When running pihole -g i get the following error message:
[i] Building tree...
  [✗] Unable to build gravity tree in /etc/pihole/gravity.db_temp

  [i] If you have a large amount of domains, make sure your Pi-hole has enough RAM available

I have 12.000.000 domains on blocklists, was newer a problem with v5.

Duplicate issue #6006: Very slow performance of UI and Gravity update
Created: 2025-02-25T09:27:04Z
Versions
Core version is v6.0.4 (Latest: v6.0.4)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)
Platform

OS and version:  Debian 12
Platform:  Proxmox (v8.3.3) LXC

Expected behavior
Smooth and usable UI.
No delays when clicking on menu items. Much faster update of Gravity, ideally the same speed or faster than in v5. Interface should display data / charts as it should be and not placeholders that show that content is currently loading.
Actual behavior / bug
I have just installed Pi-hole on the system. After I opened the interface for the first time, I wanted to open the Pi-hole diagnosis. It took almost 1 minute from the click to the final opening of the page.
Other affected points:
Domains,
Lists,
Settings > Web Interface/API,
Tools > Pi-hole diagnosis,
Tools > Tail log files > pihole/FTL/webserver.log,
Tools > Interfaces,
Tools > Network,
Dashboard,
Query Log
Also the update of gravity takes very loooo...ooong.
Before it took, let's say, half an hour, now with pi-hole v6 it tooks even several hours.
I can't work with v6, so I returned to v5.
This v6 installation is only for testing if the problems are solved and as a marker, if I can move from v5 to v6 again.
Steps to reproduce

Install pi-hole in a proxmox lxc.
open the web ui.
try to click the mentioned points.

Debug Token
[✓] Your debug token is: https://tricorder.pi-hole.net/iTAJvtHq/
Screenshots
The slowlyness isn't visible on a static screenshot.
Additional context
The same, on a Synology Diskstation DS918+ on which pi-hole runs in a docker container (Container Manager).

Closing comment (2025-02-25T10:43:34Z): Gravity issue sounds like a duplicate of #5904 for we already have a fixed.
yes, indeed, it's the same. sorry for doubling it.
But, the fix doesn't work for me. Only increasing the RAM / Swap helped. But let's move for this to the other post. #5904.
And... yes, web interface issue is definitely a duplicate of pi-hole/FTL#2284.
I can confirm, that it is a Safari problem. any other browser have either hardly or even no problems. In Safari a double click shows the wanted page, while after the single click it lasts almost up to 1 min. until the page is shown.
But also here, let's move to pi-hole/FTL#2284.
Repository: pi-hole/pi-hole

Issue #2569: Active DHCP leases list doesn't show proper MAC address
Created: 2018-12-31T14:27:06Z
Pi-hole Version v4.1.1
Web Interface Version v4.1.1
FTL Version v4.1.2
After enabling the DHCP server on my pi-hole and pointing my fritz.box to the pi-hole as custom DHCP server, I get correct MAC address listings for the IPv4 leases but I'm doubtful about the MAC addresses for the IPv6 leases (9 digit integers).

Duplicate issue #3114: Wrong Mac Adresses in DHCP leases section if there is an IPv6 device
Created: 2020-02-04T20:06:53Z
In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
1

Expected behaviour:
a list of network devices with MAC adresses IPs and Hostnames
Actual behaviour:
a list of network devices with MAC adresses IPs and Hostnames. But if there is an IPv6 Adress, the MAC adress looks like: 62140057 or just 0 
Steps to reproduce:
enable DHCP on Pihole. Add IpV6 Devices to the Network
Debug token provided by uploading pihole -d log:
Debug Log
A image tells you what i mean

Closing comment (2021-08-12T19:45:44Z): Closing as duplicate of #2569
Repository: pi-hole/web

Issue #2051: api.php status weird behavior?
Created: 2022-01-06T00:07:52Z
Versions

Pi-hole version is v5.8.1 (Latest: v5.8.1)
AdminLTE version is v5.10.1 (Latest: v5.10.1)
FTL version is v5.13 (Latest: v5.13)

Platform

OS and version:  latest raspberry pi os
Platform:  raspberry pi 3b+

Expected behavior
http:///admin/api.php?status should return the status, but it always returns
{"status": "disabled"}
this seems to break things like PiHole Chrome Brower Extension
if i leave out the status, it correctly returns the status.
http:///admin/api.php
{
    "domains_being_blocked": 534171,
    "dns_queries_today": 44,
    "ads_blocked_today": 0,
    "ads_percentage_today": 0,
    "unique_domains": 24,
    "queries_forwarded": 24,
    "queries_cached": 20,
    "clients_ever_seen": 2,
    "unique_clients": 2,
    "dns_queries_all_types": 41,
    "reply_NODATA": 0,
    "reply_NXDOMAIN": 6,
    "reply_CNAME": 0,
    "reply_IP": 0,
    "privacy_level": 0,
    "status": "enabled",
    "gravity_last_updated": {
        "file_exists": true,
        "absolute": 1641426659,
        "relative": {
            "days": 0,
            "hours": 0,
            "minutes": 15
        }
    }
}

Is this expected behavior? the api.php has code that looks for $_GET['status'] so it seems like using query parameter is the right thing.. unclear tho, since there is no API documentation to reference.

Duplicate issue #2064: admin/api.php?status always returns disabled
Created: 2022-01-09T16:15:06Z
Versions

Pi-hole:  5.8.1
AdminLTE:  5.10.1
FTL:  5.13

Platform

OS and version:  Raspberry Pi OS
Platform:  Docker

Expected behavior
GET
http://<pi_ip>/admin/api.php?status&auth=
Should return enabled or disabled
Actual behavior / bug
It returns always disabled for me
Steps to reproduce
Steps to reproduce the behavior:

execute http://<pi_ip>/admin/api.php?enabled&auth=
Check response = enabled
Execute http://<pi_ip>/admin/api.php?status&auth=
See that always disabled is returned

Debug Token
Screenshots
Additional context

Closing comment (2022-01-09T16:17:41Z): Duplicate of #2051
Repository: pi-hole/web

Issue #603: Clients over time popover gets cut off
Created: 2017-10-14T03:39:26Z
In raising this issue, I confirm the following:

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated
 The issue I'm reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the codebase?:
3



The new Clients over Time popover gets cut off, rendering it basically unusable for determining which client made a huge spike in queries.

Duplicate issue #697: tooltip hide client information
Created: 2018-03-16T10:15:36Z
In raising this issue, I confirm the following:

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
3
Expected behaviour:
the client chart tooltip should show me a list of the most active clients
Actual behaviour:
the list of clients on the graph is completely cut off as it disappears under another widget
Steps to reproduce:

have many clients logged on
open the administration page
mouse over the customer graph

Misc
video -> https://youtu.be/buu_qWDVuLQ
Solutions

move the height position of the tooltip to the beginning of the client graph
show only the first 5 most active customers

Closing comment (2018-03-16T10:17:07Z): The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).


And yet, Duplicate of: #603
😉
Repository: pi-hole/web

Issue #2048: API: the 'summary' call now returns numbers instead of strings
Created: 2022-01-05T21:38:04Z
Versions


Pi-hole:  v5.8
AdminLTE:  v5.10
FTL:  v5.13

Platform


OS and version:  Raspberry Pi OS



Platform:  Raspberry Pi 4

Expected behavior
Before, the summary API call returned data of type String for most values - whereas the summaryRaw call would return the raw numbers (Int/Double).
Actual behavior / bug
Now, the summary call returns numbers, it seems identical to the summaryRaw API call.
API Call
Replace IP with your IP, ofcourse.
http://192.168.1.68/admin/api.php?summary
http://192.168.1.68/admin/api.php?summaryRaw
Additional Context
This makes life hard for my Pi-hole Remote companion app for iOS.

Duplicate issue #2066: 3rd party apps cannot communicate with PiHole using AdminLTE 5.10.1 API
Created: 2022-01-10T15:13:10Z
Versions

Pi-hole version is v5.8.1 (Latest: v5.8.1)
AdminLTE version is v5.10.1 (Latest: v5.10.1)
FTL version is v5.13 (Latest: v5.13)
Platform


OS and version:


Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal
Expected behavior
all third part browser extensions using API to communicate with Pihole broke once Pihole Web updated to 5.10.1
Steps to reproduce
tird party appp say Pihole is disabled when it is in face not disabled and enabling them doesnt work

Closing comment (2022-01-10T19:16:25Z): In which case:
Duplicate of #2048
and (should be) fixed in next release
Repository: pi-hole/web

Issue #2051: api.php status weird behavior?
Created: 2022-01-06T00:07:52Z
Versions

Pi-hole version is v5.8.1 (Latest: v5.8.1)
AdminLTE version is v5.10.1 (Latest: v5.10.1)
FTL version is v5.13 (Latest: v5.13)

Platform

OS and version:  latest raspberry pi os
Platform:  raspberry pi 3b+

Expected behavior
http:///admin/api.php?status should return the status, but it always returns
{"status": "disabled"}
this seems to break things like PiHole Chrome Brower Extension
if i leave out the status, it correctly returns the status.
http:///admin/api.php
{
    "domains_being_blocked": 534171,
    "dns_queries_today": 44,
    "ads_blocked_today": 0,
    "ads_percentage_today": 0,
    "unique_domains": 24,
    "queries_forwarded": 24,
    "queries_cached": 20,
    "clients_ever_seen": 2,
    "unique_clients": 2,
    "dns_queries_all_types": 41,
    "reply_NODATA": 0,
    "reply_NXDOMAIN": 6,
    "reply_CNAME": 0,
    "reply_IP": 0,
    "privacy_level": 0,
    "status": "enabled",
    "gravity_last_updated": {
        "file_exists": true,
        "absolute": 1641426659,
        "relative": {
            "days": 0,
            "hours": 0,
            "minutes": 15
        }
    }
}

Is this expected behavior? the api.php has code that looks for $_GET['status'] so it seems like using query parameter is the right thing.. unclear tho, since there is no API documentation to reference.

Duplicate issue #2080: Pihole API status request always returning disabled as status
Created: 2022-01-15T21:45:22Z
Versions

Pi-hole:  5.8.1
AdminLTE:  5.13
FTL:  5.10.1

Platform

OS and version:  Debian 11
Platform:  Raspberry Pi, Docker

Expected behavior
When using the command http://pi.hole/admin/api.php?status the results should be {"status":"enabled"} or {"status":"disabled"} according to the current status of Pi-hole.
This result should match the information contained on the result from http://pi.hole/admin/api.php
Actual behavior / bug
When using the command http://pi.hole/admin/api.php?status the result is always the following:
{"status":"disabled"}
Even when Pi-hole is running:

If you compare this with the full result of http://pi.hole/admin/api.php the status does not matches either:
{"domains_being_blocked":126559,"dns_queries_today":27264,"ads_blocked_today":2605,"ads_percentage_today":9.554724,"unique_domains":1615,"queries_forwarded":17477,"queries_cached":6998,"clients_ever_seen":14,"unique_clients":13,"dns_queries_all_types":27264,"reply_NODATA":128,"reply_NXDOMAIN":41,"reply_CNAME":352,"reply_IP":436,"privacy_level":0,"status":"enabled","gravity_last_updated":{"file_exists":true,"absolute":1642177518,"relative":{"days":1,"hours":5,"minutes":13}}}
Steps to reproduce
Steps to reproduce the behavior:

Open web browser
Write the following on address bar http://pi.hole/admin/api.php?status
See error

Additional context
This was working before the latest update. I am not a programmer and only starting with some raspberry pi projects so excuse any lack of proper context.

Closing comment (2022-01-15T21:53:48Z): Duplicate of:

#2051
#2053
#2056
#2064
pi-hole/docker-pi-hole#983

Fixed by #2052
Repository: pi-hole/web

Issue #697: tooltip hide client information
Created: 2018-03-16T10:15:36Z
In raising this issue, I confirm the following:

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
3
Expected behaviour:
the client chart tooltip should show me a list of the most active clients
Actual behaviour:
the list of clients on the graph is completely cut off as it disappears under another widget
Steps to reproduce:

have many clients logged on
open the administration page
mouse over the customer graph

Misc
video -> https://youtu.be/buu_qWDVuLQ
Solutions

move the height position of the tooltip to the beginning of the client graph
show only the first 5 most active customers

Duplicate issue #741: Tooltips cut off under "forward destinations graph" [FTLDNS]
Created: 2018-04-30T05:03:52Z
In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
1

Expected behaviour:
Tooltips should not be cut off, like how it is in the "clients" graph (FTLDNS exclusive patch)
Actual behaviour:
If tooltip is too long, it gets cut off along the sides
Steps to reproduce:
If the forward destinatiion name is too long, hover over it and you'll see it gets cut off on the left side
Debug token provided by uploading pihole -d log:
n/a
Troubleshooting undertaken, and/or other relevant information:
Nothing. I'm not familliar with the page's code

Closing comment (2018-04-30T05:06:07Z): Duplicate of #697 among many others. Please check the open and closed issues.
Repository: pi-hole/web

Issue #2335: Unable to add regex to blacklist all domains
Created: 2022-09-07T14:23:53Z
Versions


Pi-hole version is v5.12 (Latest: v5.12)
AdminLTE version is v5.14.2 (Latest: v5.14.2)
FTL version is v5.17 (Latest: v5.17)

Platform


OS and version:  Debian 11



Platform:  HP Thinclient T570 (I think?)

Expected behavior
I am doing a fresh install of PiHole on a new machine due to my existing machine on Ubuntu 18.04 Server that will not upgrade to the latest FTL (stuck on v5.16.1).
I did a fresh install of Debian 11 (supports 32 bit machines).  On my previous machine, I was able to add .*? as a whiltelist and a blacklist, and then apply these to "Unrestricted" and "BlockEverything" groups so I can allow all network devices to either have full access or block all DNS lookups.  This works as intended on the existing machine.  On the new machine, when I add these same regex entries using the UI, it simply adds a blank space ( ).
Existing machine on v5.16.1:

New machine on v5.17:

Actual behavior / bug
I am unable to add an all-domain regex filter to blacklist/whitelist all domains
Steps to reproduce
Steps to reproduce the behavior:

Navigate to the Domains page and open the RegEx Filter tab
Attempt to add the following regex filter .*? as either blacklist or whitelist

Debug Token

URL:  https://tricorder.pi-hole.net/huCptCyi/


Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Duplicate issue #2343: New blacklist RegEx patterns appearing empty
Created: 2022-09-11T18:30:23Z
Versions


Pi-hole:  5.12
AdminLTE:  5.14.2
FTL:  5.17

Platform

OS and version:  Debian 11 bullseye
Platform:  VM

Expected behavior
After adding a regex pattern to blacklist, the pattern should be listed inside code block of the newly created row.
Actual behavior / bug
After adding a regex pattern to blacklist, the code block of the newly created row is empty.
Steps to reproduce
Steps to reproduce the behavior:

Go to 'Domains'
Click on 'RegEx Filter'
Add to blacklist .+.online$

Debug Token

URL:  https://tricorder.pi-hole.net/agrD12yY/

Screenshots

Additional context

Closing comment (2022-09-11T18:56:58Z): Technically, this is a duplicate of #2335.
It's fixed already and will be part of the next Pi-hole version.
Repository: pi-hole/web

Issue #1493: Flushing network table in v5.1 gives PHP error
Created: 2020-07-16T14:11:47Z
In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
1

Expected behavior:
No error should appear.
Actual behavior:
Flushing network table via Settings/System gives a PHP error:
 PHP error (2): implode(): Invalid arguments passed in /var/www/html/admin/scripts/pi-hole/php/savesettings.php:741
The flush itself is successful.
Steps to reproduce:
Flushing network table via Settings/System.

Duplicate issue #1505: PHP error (2): implode(): Invalid arguments passed in /var/www/html/admin/scripts/pi-hole/php/savesettings.php:741
Created: 2020-07-16T18:19:51Z
In raising this issue, I confirm the following (please check boxes, eg [X]) Failure to fill the template will close your issue:

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated
 The issue I am reporting isn't a duplicate

How familiar are you with the codebase?:
1

[BUG | ISSUE] Expected Behaviour:
No error
[BUG | ISSUE] Actual Behaviour:
There was a problem applying your settings.
Debugging information:
PHP error (2): implode(): Invalid arguments passed in /var/www/html/admin/scripts/pi-hole/php/savesettings.php:741
[BUG | ISSUE] Steps to reproduce:
After hitting the flush network table in settings I got the error
Log file output [if available]
output
Device specifics
Hardware Type: vm
OS: ubuntu 18..04
This template was created based on the work of udemy-dl.

Closing comment (2020-07-16T18:31:57Z): Thanks for the report, but this is a duplicate of
#1493
Repository: pi-hole/web

Issue #1524: encoded HTML displaying in DHCP tables
Created: 2020-07-22T16:17:16Z
In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

 I have read and understood the contributors guide.
 The issue I am reporting can be replicated.
 The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
1

Expected behavior:
Unknown hosts in Active DHCP leases table (#HOSTS) should be italicized.
Actual behavior:
em element set via jQuery.html() is encoded resulting in display of text string '<em>Unknown</em>' instead of decoded value 'Unknown'
relevant commit: a99bfea
Steps to reproduce:

update to piHole v5.1.1
add device to network w/o DHCP host name entry
visit /admin/settings.php?tab=piholedhcp
view "Currently Active DHCP Leases" table.

Debug token provided by uploading pihole -d log:
N/A
Troubleshooting undertaken, and/or other relevant information:
replace  .html() call with .text() and chain .css()
 $("td:eq(3)", row).text("Unknown").css("font-style", "italic");
This would also address concerns in #1434
As to why this is happening, it's unclear.  This is the appropriate use of the .html() method, however there is this note in the jQuery documentation:

This method uses the browser's innerHTML property. Some browsers may not generate a DOM that exactly replicates the HTML source provided.

Duplicate issue #1552: DHCP Leases table doesn't style content wrapped in HTML tags
Created: 2020-08-11T14:34:56Z
Describe the bug
The DHCP leases table under Settings > DHCP wraps unknown Hostnames in <i> </i> but it doesn't display these as italics
To Reproduce

Go to pi.hole/admin/settings.php?tab=piholedhcp
Scroll down to 'DHCP leases'
See error if Hostnames appear as "unknown" wrapped in italic HTML tags plain text.

Expected behavior
"unknown" to appear without HTML tags
Screenshots

Versions

OS: macOS
Browser: Chrome 84.0.4147.105, Safari 13.1.1
Web interface: 5.1.1

Closing comment (2020-08-11T14:59:38Z): Thanks for the report. Duplicate of #1524
Fixed by #1509
Repository: pi-hole/web

Issue #2051: api.php status weird behavior?
Created: 2022-01-06T00:07:52Z
Versions

Pi-hole version is v5.8.1 (Latest: v5.8.1)
AdminLTE version is v5.10.1 (Latest: v5.10.1)
FTL version is v5.13 (Latest: v5.13)

Platform

OS and version:  latest raspberry pi os
Platform:  raspberry pi 3b+

Expected behavior
http:///admin/api.php?status should return the status, but it always returns
{"status": "disabled"}
this seems to break things like PiHole Chrome Brower Extension
if i leave out the status, it correctly returns the status.
http:///admin/api.php
{
    "domains_being_blocked": 534171,
    "dns_queries_today": 44,
    "ads_blocked_today": 0,
    "ads_percentage_today": 0,
    "unique_domains": 24,
    "queries_forwarded": 24,
    "queries_cached": 20,
    "clients_ever_seen": 2,
    "unique_clients": 2,
    "dns_queries_all_types": 41,
    "reply_NODATA": 0,
    "reply_NXDOMAIN": 6,
    "reply_CNAME": 0,
    "reply_IP": 0,
    "privacy_level": 0,
    "status": "enabled",
    "gravity_last_updated": {
        "file_exists": true,
        "absolute": 1641426659,
        "relative": {
            "days": 0,
            "hours": 0,
            "minutes": 15
        }
    }
}

Is this expected behavior? the api.php has code that looks for $_GET['status'] so it seems like using query parameter is the right thing.. unclear tho, since there is no API documentation to reference.

Duplicate issue #2053: Api status return wrong info
Created: 2022-01-06T16:10:32Z
Pi-hole v5.8.1
FTL v5.13
Web Interface v5.10.1

If i run “pihole -c” i have correct information
(Active)
 Pi-hole Chronometer                                                                                  
             
            Press Ctrl-C to exit
            ——————————————————————————————————————————————————————————
  Hostname: vUbuntu            (Ubuntu Fossa 20.04)
    Uptime: 2 days, 01:53:20                       
 Task Load: 0.02 0.08 0.08     (Active: 1 of 155 tasks)
 CPU usage: 1%                 (8x 1.6 GHz)
 RAM usage: 20%                (Used: 3 GB of 16 GB)
 HDD usage: 73%                (Used: 34 GB of 49 GB)
DHCP usage: 15%                (Leased: 3 of 20)
   Pi-hole: Active             (Blocking: 3063531 sites)
 Ads Today: 7%                 (Total: 9519 of 130531)
Local Qrys: 42%                (1 DNS servers)

but if i check api

curl -s http://192.168.x.x/admin/api.php?status\&auth=XXXXX

{"status":"disabled"}   


it return DISABLED

Closing comment (2022-01-06T16:13:51Z): Duplicate of #2051