Seemingly unconnected file causing header mash up

[TechnoDiver]

Good morning folks, I'm having an obscure issue with previously sent headers.

I have an add_category.php for the admin backend of an app I'm working on. It was working fine until I added a Post.php class, but the Post.php class doesn't even interact with add_categories.php outside the initialization file. When I use this file to add a category I get the normal

Quote

 

Warning: Cannot modify header information - headers already sent by (output started at /opt/lampp/htdocs/qcic/assets/class/Post.php:94) in /opt/lampp/htdocs/qcic/admin/category.php on line 6

 

Like I said, this was working fine until I added the Post.php class. But the only time that they even come close to interacting is in the initializations.php which I put at the top of each of the pages and looks like this ->

<?php
require("../load.php");

require("../assets/class/User.php");
require("../assets/class/Category.php");
require("../assets/class/Post.php");

$user = $user_obj->getUsername(); 
$role = $user_obj->getRole();

$cat_obj = new Category($conn, $user);
$post_obj = new Post($conn, $user);

The relevant code for the add_category.php is ->

<?php
require("assets/initializations.php");

if(isset($_POST['add_cat'])) {
  $cat_obj->addCategory($_POST['cat_title']);
  header("Location: category.php?message=category-added");
  exit;
  } 
?>

After some research I've altered this a bit to this ->

<?php
require("assets/initializations.php");

if(isset($_POST['add_cat'])) {
  $cat_obj->addCategory($_POST['cat_title']);
  if(!headers_sent()) {
    header("Location: category.php?message=category-added");
    exit;
  } else {
    var_dump(headers_list());
  }
}
?>

Which returns this ->

Quote

array(5) { [0]=> string(23) "X-Powered-By: PHP/8.0.3" [1]=> string(38) "Expires: Thu, 19 Nov 1981 08:52:00 GMT" [2]=> string(50) "Cache-Control: no-store, no-cache, must-revalidate" [3]=> string(16) "Pragma: no-cache" [4]=> string(38) "Content-type: text/html; charset=UTF-8" }

I have no idea where those are coming from or why they're coming at all and that date is a long time ago.  Some of it looks familiar, some I've never seen before. I haven't come across a remedy that works yet though. Any suggestions?

 

EDIT: typo

Edited August 2, 2021 by TechnoDiver

[Strider64]

You can resolve a lot of those issues by using an autoloader (I use composer's autoloader) and namespaces.  That way you can ensure there are no conflicts amongst your classes 99 percent of the time.

Here's an example in what I'm talking about.

<?php /** @noinspection ALL */

namespace PhotoTech;

use Exception;
use JetBrains\PhpStorm\Pure;
use DateTime;
use DateTimeZone;

class CMS extends DatabaseObject
{
    protected static string $table = "cms"; // Table Name:
    static protected array $db_columns = ['id', 'user_id', 'thumb_path', 'image_path', 'Model', 'ExposureTime', 'Aperture', 'ISO', 'FocalLength', 'author', 'heading', 'content', 'data_updated', 'date_added'];
    public $id;
    public $user_id;
    public $page;
    public $thumb_path;
    public $image_path;
    public $Model;
    public $ExposureTime;
    public $Aperture;
    public $ISO;
    public $FocalLength;
    public $author;
    public $heading;
    public $content;
    public $date_updated;
    public $date_added;

<?php
require_once 'assets/config/config.php';
require_once "vendor/autoload.php";

use PhotoTech\CMS;
use PhotoTech\Pagination;

/*
 * Using pagination in order to have a nice looking
 * website page.
 */


$current_page = $_GET['page'] ?? 1;


$per_page = 2; // Total number of records to be displayed:
$total_count = CMS::countAllPage('blog'); // Total Records in the db table:


/* Send the 3 variables to the Pagination class to be processed */
$pagination = new Pagination($current_page, $per_page, $total_count);

I'm not saying that's the issue, but it will save you a lot of headaches trying in having to rule out conflicts.

Edited August 2, 2021 by Strider64

[requinix]

Quote

Warning: Cannot modify header information - headers already sent by (output started at /opt/lampp/htdocs/qcic/assets/class/Post.php:94) in /opt/lampp/htdocs/qcic/admin/category.php on line 6

 

[TechnoDiver]

Ok, that certainly adds to the list of new things to learn concerning this project, I appreciate it and will look into it.

I'm so confused as to why this is even a conflict, I've been staring at it and changing small things since I made the OP. I've moved the post_obj instantiation out of the initializations.php file and put it in an if statement at the top of the add_posts.php file. So Post.php should only be being touched if $_POST['add_post'] is set. There's no 'add_post' in the file this is giving the header warning about.

<?php
require("assets/initializations.php");

mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT);

if(isset($_POST['add_post']) && !empty($_FILES['post_image'])) {

    $post_obj = new Post($conn, $user);

    $filename = $_FILES['post_image']['name'];
    $file_tmp_name = $_FILES['post_image']['tmp_name'];
    $filesize = $_FILES['post_image']['size'];
.....
.....

so now the $post_obj isn't even a thing at the time it's saying it's throwing out that header. And add_post.php is working as intended. What am I missing?

[TechnoDiver]

UPDATE: The resolution to this problem was moving all the class instantiations from the initializations.php file to the top of their respective pages. It seems real obvious in hindsight. I feel I think more clearly in the evenings.

 

I still don't know where that header from 1981 is from, if anyone has any info on that I'd like to hear it

[kicken]

1 hour ago, TechnoDiver said:

I still don't know where that header from 1981 is from, if anyone has any info on that I'd like to hear it

I assume you're talking about the Expires: header, that comes from session_start().  By default enabling sessions will attempt to disabling caching which is done by marking the page expired and setting the Cache-control / Pragma headers.

[maxxd]

If you've got files that are strictly php, don't use the close tag (?>). More than likely, this is where your issue is coming from - some IDEs will add a new line at the end of files. If the php is closed, this is output to the browser and will blow up any header interaction. If the php is not closed, however, it'll be interpreted as whitespace in the code and ignored.

[TechnoDiver]

On 8/3/2021 at 6:33 AM, maxxd said:

If you've got files that are strictly php, don't use the close tag (?>).

so, for example, I shouldn't close off the code in Classes? I remember Barand said something like that a few weeks ago to me and I didn't quite understand what he meant. Now I do. Thank you