Recent Profile Visitors

In both your samples I would just import the class and alias it if necessary.
namespace NotionCommotion\Domain\Repository\Account;
use NotionCommotion\Domain\Entity\Account\User;
class Account
{
public function getUser(string $mainKey, int $userId):?User {
//
}
}
I don't think the alias is necessary below, but for example.
namespace NotionCommotion\Api\Account;
use NotionCommotion\Domain\Entity\Account\Account as AccountEntity;
class AccountService
{
public function read():AccountEntity {
//
}
}

Is NotionCommotion\Domain\Entity\Account the namespace or the class?
Doing
use NotionCommotion\Domain\Entity\Account as AccoutDir;
class blah extends AccountDir\Account {
}
Is going to be looking for the class NotionCommotion\Domain\Entity\Account\Account inside namespace NotionCommotion\Domain\Entity\Account which doesn't seem to be correct to me.
Assuming the namespace is just up to the entity and account is the class name, then you'd instead just do:
use NotionCommotion\Domain\Entity;
class blah extends Entity\Account {
}

They are the same. Note the github url on the packagist page.
Generally speaking in these situations I start by designing the PHP interface I need and then try and code the necessary drivers to match that interface. As drivers are built it may be necessary to change the interface to accommodate. For example you may start with:
interface DeviceController {
public function start() : Promise;
public function stop() : Promise;
public function open() : Promise;
public function close() : Promise;
//...
}
Then, foreach device you have to support make a driver that implements that interface, for example:
class ModbusRtuDevice implements DeviceController {
private $socket;
public function __construct(SocketClient $socket){
$this->socket = $socket;
}
public function start() : Promise {
return $this->send('start');
}
public function stop() : Promise {
return $this->send('stop');
}
public function open() : Promise {
return $this->send('open');
}
public function close() : Promise {
return $this->send('close');
}
private function send($action) : Promise {
$command = json_encode([
'action' => $action
, 'arguments' => []
]);
return $this->socket->sendCommand($data);
}
}
The just code the rest of your application according to the DeviceController interface.
I'd focus first on just creating an interface that you'd ideally want. Then focus on implementing a driver for it for whatever your most common device type is. Adjust the interface design where required as problems arise. Once that is working, move on to implementing a driver for the next most common devices. Again, adjust the interface as required but keep in mind your first driver. If a change is needed and avoid just adding some driver specific method/parameter. Adjust the interface to something that works for both devices and make the adjustments to the original driver as needed to accommodate the new interface design.
A lot of this is sometimes easier said than done, I know. Sometimes it may take quite a few iterations to really get things in a good place.

As requinix suggested in the last post, I would probably just have your client object (or some other object) take both a socket and a protocol as arguments. The protocol object is responsible for parsing/generating byte streams according to the rules of the protocol. The socket object is responsible for transmitting and receiving those byte streams across the network. The client object coordinates those two jobs.
<?php
class ProtocolFrame {
}
class Protocol {
public function parseStream(string $bytes) : ProtocolFrame;
public function serializeFrame(ProtocolFrame $frame) : string;
}
class SocketClient {
public function __construct($host, $port);
public function read() : string;
public function write(string $bytes) : int;
}
class Client {
public function __construct(SocketClient $socket, Protocol $protocol);
}
I'd have to know more about the protocols and such you have to deal with to make a better suggestion. If you can't come up with a common interface that you can implement for each protocol it may make things more complicated.
The above example makes a few assumptions, namely that your protocols are based on sending distinct packets/frames that can be divided up. If not, adjust accordingly. Instead of a generic serializeFrame method you might instead make more specific methods like sendGreeting() or changePosition() or whatever.
Having the protocol objects just generate frames/byte streams rather than work with a socket may allow for easier testing as well as you can just compare the generated data to some correct string constants or whatever rather than having to mock up a socket object.
I think this is something that you should look at more. Maybe your right in that a single interface isn't possible, but you definitely want to spend some time and think about it. If your concern is some protocols taking longer to do something than others, maybe use something like react/promise to handle the difference in timing. If it's an issue that one protocol needs extra details that others don't, maybe there is a way to get that information to the protocol via some other method (like a second interface maybe).
Perhaps post another topic about a specific case with details if you're stuck and want some help there.

Yes, if you dont need any of the data and just want to start fresh then just delete all the existing partitions and create new ones to your liking. OS installers usually provide a way to do this during the install process but you could just use any partition tool as well.

B/C can be instead written as:
$result = json_decode(curl_exec($ch));
$trackingNumber = $_SESSION["trackingNumber"] = $result->parcelTrackingNumber;
Creating a different local variable rather than using the session (or post/get/whatever) array can be useful to reduce typing. This is the primary reason I do such things from time to time.
Even with an editor that has good auto-complete it is frequently easier/faster to reference a simple variable rather than an array key.

@TinLy, Unless your client has direct access to your database some how, presumably they are changing it by making a request to some script you have on the server and sending it information. If that's true then you can simply "do something" at that point rather than having to constantly poll your database.
Otherwise, stick with polling if you want but limit your query rate to something acceptable which might mean the detection of said change may be delayed a bit. For example, maybe wait a minute etween checks, or 5 minutes if that's still too much.
You're being too vague about your situation to really provide any better help. If you need more help you'll have to start getting into specifics instead of just saying "something changed", "do something", "client", etc.

Not really no. If you want to know the content of your database you have to query for it.
If you explain more about what your goal is then perhaps there is an alternate solution. For example, maybe you should just "do something" in the same place that you change your database, then you won't have to query it constantly to detect a change.

It is, but the idea is that you could use that to guide your serialization.
You'd create a schema that describes the end result of the JSON output you need. That schema would then end up list the objects and properties that make up that json output. You could then write a class that reads that data from the schema and finds those properties on the objects you pass it to generate the JSON output.
When I was looking into a while back it that was essentially what I was thinking of doing. I had an API that accepted and responded with JSON. I was going to define a schema for each endpoint to validate that POST'ed json data was valid. The idea was to then also serialize responses by using the schema. I never got that far with it though as things changed.
You don't have to do it within your entity. I wouldn't say there's anything wrong with it in this case though. The part of the code that is part of your entity would just be returning the data that should be serialized. The actual serialization process would still be in a separate service class.
Like most things it's a trade off between what gets the job done what what might be an ideal solution. The ideal solution might involve a number of classes and mapping files to configure what data to pull from what objects. That'd take time to design an implement though. A service that just asks the entity directly for the data would be simpler and easier to implement, but maybe less flexible and muddies up the entities a bit.
I find a lot of the times it's better to start with the less ideal solution that works so you can get a better understanding of what you actually need to do (vs what you think you'll need to do) then you can re-factor that into a better solution later on.

I don't understand why you have your $bDiffName and getBDiffName() instead of just overriding getB(). If both properties serialize as 'b' I don't see the point in separating them.
If the JSON Schema doesn't work for you that's fine. What you could do is just define your own JsonSerilzable like interface that your entities implement. You could either have separate methods to create your different representations or one method that you pass some parameters too in order to determine the proper serialization.

If you need different views for the same object then I'd suggest creating a separate service that handles that. Pass it the object(s) you want to serialize and the type of view you want and let it handle the serialization rather than the entity with JsonSerializable.
For example, maybe write a class that takes an object and a JSON Schema and will serialize the object according to that schema. Then you can just create a different schema for each data view you need. I looked into doing something like this once, but ended up going a different direction that made it not necessary.

A form field is a form field, whether it's hidden or not is irrelevant. Your user has control over it's value so you always have to validate the data. So long as you do that and take proper precautions such as prepared statements for any queries using those values you're fine.
Just don't ever assume that because it's hidden the value can be trusted. Ie, don't do something like
<td>
<form id="offer01" action="" method="post">
<input name="planID" type="hidden" value="mp-1111">
<input name="planPrice" type="hidden" value="20">
<input name="planSelected" type="submit" value="Select">
</form>
</td>
And assume that someone can't change the price field because it's hidden.

If you're developing them as essentially separate sites I'd probably give them separate repositories as well. I'd also use separate domains such as www.example.com and admin.example.com, which would then end up being separate folders on disk such as /var/www/www.example.com/ and /var/www/admin.example.com/
Whatever works best for you and makes sense is probably fine though.
I'm currently working on an API for an existing site. Like you the API and the site share the same database but are separate things more or less. The API has it's own git repository and is stored on a separate folder on the server. Since I don't control to domain it'll end up just being a sub-folder of the current site via an Alias /api /var/www/example-api in the server configuration.

If you're data is getting duplicated then you're calling mysqli_query twice with your insert query. mysqli_insert_id doesn't cause duplication, it just returns the id generated by the previous insert query.
Also, if you want to prevent duplicate email addresses you should have a UNIQUE constraint on that column, not query the table first.

It sounds like you're host may have installed something like mod_security and your post data is getting caught as a possible sql injection attempt.
You might be able to disable it.
Otherwise, you may just have to re-structure your data to avoid it.
I'm not really familiar with mod_security. Never used it or anything similar in my setups.