Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by requinix

  1. 7 minutes ago, mark107 said:

    When I store my emails in a database, do I need to delete the emails on the server?

    Storing the emails in the database does not mean copying them. It means that is the source of emails. There is no IMAP server anymore. There is nothing to delete.

    7 minutes ago, mark107 said:

    I have the attachments stored on my server but how I can store the attachments? do i need to store the files name in a database or what?

    Attachments are not separate files. They're part of the email message itself.

    7 minutes ago, mark107 said:

    And when I open my emails, do I need to use imap or database to fetch my emails?

    ...I'm not sure you actually understand what you're talking about anymore.

  2. If you're fine with your client being the only means to access emails then sure, go ahead and store them in a database. The process depends on your mail server, but generally they have some sort of plugin that would be relevant - run a script when a message arrives, something like that.

    If not, or if you don't have control over your mail server, then stick with PHP. You can cache email content in the database in order to reduce the bandwidth between PHP and the IMAP server, but you should still be querying it for basic information (eg, message lists) in case that's modified by some other mail client.

  3. Create a view for yourself that shows threads and the initial posts. It'll make life easier. Though I'm really skeptical that XenForo doesn't have a way to get that information sort of finding the first post for a given thread ID - after all, since there is an ID in the first place, surely there is some source generating that ID, right?

    Once you have the view the query to find users is trivial.

    • Like 1

  4. 2 hours ago, NotionCommotion said:

    This what you had in mind?

    Yup. Personally I would also be tracking the nodes as members of the chart itself, but that's besides the point.

    2 hours ago, NotionCommotion said:

    One thing I might rather do different is instead of cloning the nodes in the chart entity, clone them in the chart's serie entity and set the newly cloned notes in the category entity.  The problem, however, is using SplObjectStorage in the chart as I have done, the category does not have access to these newly cloned nodes.  Should I abandon trying to do so?

    Sounds too complicated.

    Speaking of complicated, you could create a NodeCollection object that offers iteration by category and series. The series and category objects then use that collection instead of managing their nodes manually. I'm leaning towards this.

    2 hours ago, NotionCommotion said:

    When setting the parent entity which belongs in a collection, I am also adding to the collection as shown, and do the same for the CategoryChartSerie's and CategoryChartCategory's.  Is doing so good practice?  Is it best to set the reciprocating properties always in the child entity as I have done or instead do it in the parent entity?

    Having links on both ends makes it harder to move things around, as you have to remember to update both links, but it's not too unreasonable to do so.

    2 hours ago, NotionCommotion said:

    When cloning, I often see the following check before cloning.  Recommended?

        public function __clone()
            if ($this->id) {

    Meh. If the id isn't set then there's no operations to clear it, but instead it adds operations to check the value. More lines of code for no net benefit.

    2 hours ago, NotionCommotion said:

    Lastly, you stated that the nodes must be cloned.  While I do not disagree, is the reason this is necessary that Doctrine must be internally using the node's hash to keep track of them?

    The nodes must be cloned because they can/should only belong to one chart. No cloning means you are reusing them in two places. Same reason you have to clone the series and categories.

    • Like 1

  5. Here's how Apache and PHP handle a request. Basically.

    1. Browser sends a request to Apache. It has lots of information but all we care about is the URI (URL) that it wants. Such as "/topic/309212-apache22-with-php52-nothing-returned-from-php-on-xp/".
    2. Apache takes that URL and figures out what file it corresponds to. There's a lot that can happen here, but what matters here is that Apache found a (in this case) .html file.
    3a. Now it has to decide what to do with the file. Are there any modules configured that want to deal with .html files? No. Additionally, .html probably means the "text/html" type. Are there any modules to deal with text/html? No. Apache dumps the file out to the browser.
    3b. Say it was a .php file instead. There are a couple ways to configure PHP but let's pick the file extension one. Any modules for .php? Yes: mod_php. Apache tells mod_php to do whatever it wants to do.
    3c. The other method is very similar: nothing to handle .php, however Apache knows the file as application/x-php (or something) and there is a module (mod_php) to handle that.

    Apache doesn't care about what's in the file. It cares about what type of file it is, either by extension or by type. Your setup is presumably using the .php extension (or application/x-php-something type) because that's what normal people do. Thus Apache does not know your .html files should go through PHP. Thus what you need to do is actually tell Apache that you want .html (aka text/html) files to go through mod_php, and you do that by tweaking your current "set up PHP in Apache" configuration, which may be by extension or by type, to include HTML files.

  6. 18 minutes ago, NotionCommotion said:

    What do you mean by a "(deep)" clone?

    A deep copy/clone is when you clone an object and all the other objects "in" it. What you are doing now, where your __clone also clones the series and categories in it.

    A shallow copy is when you don't do that.

    18 minutes ago, NotionCommotion said:

    Where I am having problems is with the Node objects which are in a collection in both Serie and Category.  I can clone each node in a series, but then I still have old nodes in the collection and I can't just clone those nodes in the collection because they need to be the same instances as in the series.  Same is true if I do the categories first and then the series.  So, instead I tried to replace the series and categories in each node with the newly cloned series and categories, but that doesn't change the node entities so no good.

    You must clone nodes. You have to. Can't avoid that. So anything you come up with that doesn't clone the nodes will not work correctly.

    Cloning the nodes according to the series won't let you update the category. Cloning the nodes according to the categories won't let you update the series. So come up with another method: one that lets you discover all the nodes and update their series and category correctly. Hint: as you clone the series and categories, keep track of what which objects are taking the place of which old objects...

  7. First, you need-- actually no, it can wait until you discover it for yourself.

    convertBash() takes a string line of output as an argument and returns a new string with HTML markup. fread() reads from the process and returns a string line of output.

    So instead of echoing the line of output, you run that line through convertBash and echo what it returns.

  8. On 9/10/2019 at 6:05 PM, NotionCommotion said:

    I wish to clone the chart entity and thus use __clone() to set the chart, category, and serie entity's' PK to NULL, however, am running into issues as the node entity still has the original entitiy's PKs.

    Then your cloning is faulty.

    1. If a chart "has a" set of series and categories, then a (deep) clone of the chart should also clone those sets.
    2. A clone of a database entity should reset the object to a "new" state - ie, unset the key, mark the object as "new", and/or affect whatever else your abstraction library uses.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.