Problems with custom block delete function

Permalink
I'm developing a block, which when added, creates a sub-page under current page, and adds some custom values to a different table.
And when deleting the block it would also delete assigned sub-page and remove custom data from table.
Now, the situation is this:
if block has been just added but not yet published, deleting the block does remove the sub-page and custom data, but if block is added and changes published, deleting the block does not remove the sub-page nor the data. I have to edit block and then save it in order to correctly remove.
What I can gather is either something is wrong with delete function, or current(selected) block bID is returned as null.

this is delete function I use in controller.php:

public function delete() {
$db = Loader::dB();
$childID = $db->GetOne("SELECT childID FROM btPrekiuKatalogas WHERE bID=?", array($this->bID));
$db->Execute("DELETE FROM btPreke WHERE childID=?", array($childID));
page::getByID($childID)->delete();
parent::delete();
}

where btPrekiuKatalogas is current block table, btPreke is custom table where data is added and removed, and childID is a sub-page id.

I would really appreciate any help with the matter.

silvercrest
 
JohntheFish replied on at Permalink Reply
JohntheFish
When adding a block, a block ID does not exist until a block is saved, so up until the block has been saved then re-edited its ID will be null.
silvercrest replied on at Permalink Reply
silvercrest
understood that, is there a way to get blocks ID on delete, without re-editing?
JohntheFish replied on at Permalink Reply
JohntheFish
An added block does not actually exist until first saved, so its ID cannot exist in the dialog until you save then edit.
silvercrest replied on at Permalink Reply
silvercrest
So, each time I want to delete the block I have to edit it first to get the blocks ID? This is rather inconvenient.
Is there a way to acquire selected blocks ID? I mean, somehow concrete knows what block to remove from the area once it's selected, does it not do that by ID?
JohntheFish replied on at Permalink Reply
JohntheFish
Lets get away from this. It feels like you are banging your head repeatedly against a wall. You need to take a few steps back and look for an alternate route.

Please describe what you are actually doing from basic requirements. Then maybe I or another developer else can suggest a way of addressing your requirement that avoids this dead end.
silvercrest replied on at Permalink Reply
silvercrest
Agreed.
here it goes then :)

When added, my block, creates a sub-page in the current page and adds some relevant data to a different table. The block it self displays some data like picture, title etc, and also acts as a link to a sub-page it creates. This all works like a charm.

However, when deleting existing block, it should also remove data from said different table and a sub-page relevant to the current block.
here is my delete() function in block's controller.php:
public function delete() {   
$db = Loader::dB();
$SubPageID = $db->GetOne("SELECT SubPageID FROM btMyBlock WHERE bID=?", array($this->bID));
$db->Execute("DELETE FROM btDifferentTable WHERE SubPageID=?", array($SubPageID));
page::getByID($SubPageID)->delete();
parent::delete();
}


Now let me describe situations when that happens successfully and when it fails.
If the block is added a new and saved, but changes to the page not yet published, deleting the block DOES remove the data from a different table and the sub-page.
If existing block was edited and saved, deleting the block also successfully removes data and sub-page.
BUT if changes to page were published, deleting existing block fails to remove data from a different table and delete the sub-page.

My question would be, why does it fail?

I hope it makes some sort of sense.
JohntheFish replied on at Permalink Reply
JohntheFish
Why do you need btDifferentTable ?
silvercrest replied on at Permalink Reply
silvercrest
that table contains data needed for a sub-page block.
JohntheFish replied on at Permalink Reply
JohntheFish
When a block is edited and saved, the bID changes. Could that be getting out of step with the cross reference?

Why go about it this way round? If this was driven the other way round, by adding a page with a teaser and then pulling a list of the teasers into the parent, then many page lists (or blogs) such as Page List Teasers may achieve what you are trying to do. Pro Blog even has its own front end button to set up such structures..
silvercrest replied on at Permalink Reply
silvercrest
Well, that's the thing, client is not interested in manually adding pages and such. it has to be a single block do-it-all :)