PHPFOX

A lot of clients have been confused with the Moxi9.com website. The idea with the Moxi9 website was to put all our products that we've been working on under one common website. Due to the confusion we've decided to bring back the Product Website www.phpfox.com and this will be re-released February 25th.

The change will contain:

An updated webdesign with a simplified layout.
A new blog section - for us to provide with helpful articles on how to manage your PHPfox Social Network.
A Pre-order Page - you will be able to order PF4 for a reduced pre-order price prior to it's RC1 Release.

Do note that everyone ordering PHPfox v3.8 today will be able to access PHPfox v4 for free .

PHPfox version 4 Update

Since we announced PHPfox v4 last year we've received a tremendous amount of interest in this new version. As you might have notice we've been low-key with updating you about the new version. This is because this specific version is a very important version for us and we simply want it to be great.

We had initially released v4, using the same engine as what we have been using since v2 and introduced a new way of creating apps for our product - which was an API based app system where developers would host their products. We were about ready to release v4, but we took a minute to see the future direction the core product would take if v4 was released at this point. Products have evolved and a lot of new technology has been created over the past few years and sticking with our current engine we knew utilizing many of these awesome tools would not be fun.

The product has become rather enveloped with a large code base and database structure. As social networks have evolved and the introduction and popularity of an activity feed, our current engine wasn't designed for this in mind when it was first concepted. The engine for v3 is very modular in its nature, separating each section to have its own set of subroutines and database structure. Because of this, improving and streamlining the activity feed hasn’t been the easiest of tasks. Since a social network at its core would base itself around a feed, or in other words a stream, in our case; we felt for the future of our company and product it was necessary to improve our product by completing rewriting it from the ground up.

This has kept us rather silent the last few months, which has been really hard, but we needed to keep as much information internally until we reached a final release date. This day is now very close and we wanted to go over some of the technical improvements with our products core. This entry will not be focused on a sales pitch, but we will strictly focus on the major changes that are going to take place with the core and how it greatly has improved over our current engine.

Streams with Redis

While MySQL has served as our primary database ever since the conception of PHPfox, this version will include several other ways to store data. Our new engine is being designed to fully utilize many of the tools provided today to load balance a very large community.

Our first step was to redesign our Stream (Activity Feed). We have made it so anything added to a site that can include a form of discussion and/or liking it, is to be considered a feed. From a developers perspective, we don't need to worry about custom database structures or building full sections and will instead use the Stream to expand our apps. Streams can hold any sort of data object, which a developer can later transform into what they need. This can be from photos to forum threads. All powered by the same stream routine and comes built in with features to interact with the stream and users, such as comments, likes and restreams to name a few.

For this specific feature we went with Redis as the primary storage for streams. Since our streams design is to be a simple key-value in mind, selecting Redis was the best choice we tested over a few other options.

While, Redis will be used to power the primary stream, MySQL is still there to store static information that needs little access or contains very sensitive information. In general, pages where users would visit the most, our policy is a 0 SQL queries.

Our database routine is built over DBAL, which has support for other drivers such as PostgreSQL, Oracle, Microsoft SQL and others.

In addition to a new core code base we have a new database structure. There will be a lot less tables then what is included with v3 and thus far we have three in total. One of those tables is designed to be a meta table where we can store any data we need to keep safe and can later cache into memory, such as site settings, user groups and menus.

Messenger and Web Sockets

Another area we really wanted to improve was how users communicated with one another. This has become very bloated with v3 as it included 3 features to provide very similar ways to communicate and 2 of those where how the Mail module would work. Clients could choose if they wanted the v2 route, were messages would act as a conventional email or a conversation. In addition to that we have the Messenger, which provides a similar conversation route.

The biggest issue we have faced over the years with the messenger is we have always been bound to MySQL and moving away from that never seemed like a good time to do. With so much goodness in this realm today, we felt it was time to move away from some of our old habits, such as relying on MySQL.

To assist in improving in this area we will be using Redis to hold past conversations and HTML5 web sockets to provide a method to allow users to carry a conversation instantly.

With the introduction of web socket support with our product, this also allows us to use it in other areas, such as pushing notifications to users instantly.

Object Storage

We will not store uploaded content on HTTP servers any longer. This is to assure that you can load balance your communities without the need to use a CDN. Data uploaded to a site is stored in the database and later cached into memory and a users browser. If not using a CDN we will be advising our clients to use Varnish Cache (more about Varnish below) in front of their HTTP servers to cache uploads and even entire pages.

Optional CDN support is included and objects can be pushed to a CDN and deleted in your sites local storage.

Localization

When we first started work on v2, we were dealing with issues of non-latin characters not rendering correctly across different browsers and databases. We solved this then to convert strings into Unicode. While this solved the issue entirely, it introduced a design flaw when dealing with string lengths. When storing non-latin characters in the database it would store in average 6 characters per non-latin character. The issue in this is many of our database columns have 250 character limit, consequently taking up space much faster, while having shorter output lengths.

A lot has changed in terms of databases and PHP itself since v2s engine. With PHPs support for Multibyte this has greatly helped resolve these issues. Updating our database structure was crucial to assist in resolving this design flaw.

Translating

Phrasing of our apps will follow PHPs GetText functionality, where language packages can be modified offline and using editors designed for editing phrases.

Additionally all phrases used by apps and the core itself will be kept online and will allow group translations via Github.

On the Spot Administration

We will be stepping away from the conventional administration panel and focus on a more on-the-spot administration. You will have access to an Administration panel which is available on all pages unless toggled.

Adding menus are done directly where you visually see the menu and can reorder its structure by dragging them into a specific location or another menu block.

You can edit any page and modify its meta tags, title and append blocks to specific locations.

Blocklets

Blocks/widgets are nothing new with our product and we have tons of them in v3. One issue with blocks is it can slow down a users experience. v4 will continue to have support for blocks, but will instead use JavaScript to load the blocks (now called Blocklets) into place. It renders the block when it is ready and users can focus on checking out the main content until these blocks are loaded. Blocklets can load external CSS and/or JavaScript. Since blocklets are loaded via JavaScript, apps can decide if we can cache blocks for X amount of days. This dramatically lowers the load of your HTTP servers and allows our product to exit out of its routine a lot earlier to simply identify that the blocklet is still to load from the browsers cache.

Varnish Cache

We are designing the core to allow full page caching of all the pages on the site. If you were to then place Varnish in front of your HTTP servers this will give them a chance to breath. Using Varnish is optional and we also provide a built-in method to cache an entire page. This method still hits the HTTP servers and simply exits our core at a much earlier time. It uses browser caching to assist.

Varnish is a software that significally speeds up your Social Website while reducing your web server load. Below we've created a simple diagram to showcase the idea of how Varnish will work with your PHPfox social website.

Controller Routing for SEO

v3 provides a very lax controller routing system, which in turn creates SEO issues such as duplicate content. With us moving away from our current engine this has allowed us to develop a stricter but developer friendly routing for controllers that connect with their apps.

In addition to defining routes to controllers, developers can control what request methods are allowed as well as to close it off to users only.

Working with LESS

When developing apps we sometimes need to create additional CSS to render to fit the apps needs.

When working with our base theme we use LESS and developers can use the predefined variables our base provides to easily create new CSS that matches the sites theme.

Friends, Followers & Connections

v4 will change how users befriend with one another and will focus more on the Follow system. Users will be able to "Connect" with other users without having the other user accept their request. However, users can enable a privacy setting to approve users before they can view their profile.

Admins can in turn enable this setting by default, thus transforming it back into a Friend Request system.

Pay to View

Users can enable an option where they can charge users to view their profile. Site owners can take a percentage of each sale made by this user. This way the site admin and the user can simultaneously earn money, giving the user an incentive to be part of the Pay to View Social Website.

Ad Revenue Sharing

A persons profile has become a commodity online and we are introducing a new revenue sharing ad manager, where if Admins enable this feature; users can accept to have ads on their profile. If they do, they get a percentage of each ad viewed on their profile. Advertisers can then focus their ads based on specific criterias and in many cases on an individual they believe can sell their product.

Personal Photo Sharing

Users can personally share photos with specific members and can define how long the photo can be visible before it is removed from the system. This feature incorporates some functionality of our poke feature but focuses on having a photo in focus.

Goodbye MD5 Passwords

v2 introduced the MD5 salted passwords and we have since then kept this routine. v4 will let go of this routine and will introduce a much newer method to keep your users passwords safe.

Font Awesome

Our core says bye to conventional image icons and will include Font Awesome. Themes can of course use icons, however we will guide new themes to use our built-in icons as it allows us to easily create responsive icons and since these icons are based on fonts they match the site's color pattern and base font size.

This also gives developers access to tons of icons and not have to worry about creating new ones and having them match the sites theme. This will be easier for designer and developers to custom design/work PHPfox into a unique Social Network.

Image Manipulation

Imagick support is now included with v4. While PHP GD2 has brought tons of improvements over the years, Imagick for one is not bound to PHPs memory limit. Reducing as much stress on a servers memory limit is always a fun idea. Additionally it opens the door to some fun filters.

Apps

When developing our App system we wanted to give developers as much power as possible without the need to use any of the server side resources. In order to do this apps would have to be very lightweight and able to scale across servers or a SaaS infrastructure.

To accomplish this we needed to remove server side access to PHP and strictly keep apps written in JavaScript & HTML, while still giving server side support for things like database interactions and user authentication for example. We extend the popular templating engine Twig to provide support for all the funtionality they provide and access to some of our built-in tools to interact with the Redis database.

This gives our clients the ease of one-click installs and updates.

The new setup of developing an app will have the same method for third party developers as it will be for our internal official PHPfox developers, so any obstacle and any technical issues our third party developers face our internal developers will be able to reproduce.

This change, on how we develop apps, will help us better maintain the app system; unlike the current modular system. v3 uses modules and they differ on how the modules are installed and maintained, so we lost this point-of-view that developers faced. With the new setup it will give us a greater insight to the issues experienced by third party developer, making it easier for us to improve the app system.

The apps itself will be hosted by the client, unlike our initial v4 release, which had it hosted by developers and went through our servers. While this provides a secure way of apps in comparison to modules, it had a single point of failure, which is something none of us want to face.

Apps cannot overwrite or modify the core or other apps. When a client installs an app, developers must provide a list of scope access, which their app would need access to. This could be from uploading something to the server or allowing the app to notify users. Without the permission of a client, an app cannot access certain routines in the product. Developers can develop their apps locally and can commit changes to our repository and can push changes to go live once its ready. Once changes have been pushed live, clients are notified an upgrade is available and can then upgrade the app when they please.

Webhooks

Since apps do not have access to our core via PHP, this closes the door on conventional event driven hooks. While the core supports event-triggered hooks for those that wish to extend the core, apps can utilize webhooks. Since a webhook requires triggering a call to an external source, apps must request for access to use webhooks. Not all webhooks will be a live trigger as we don't want to slow down a users experience and instead will rely on our Queue system. For a webhook like when a user is being created this requires a trigger of the event on the spot, which is what we use to create a ReCaptcha app. In this example we create a webhook internally to the site to one of our own controllers to check the ReCaptcha post data.

Queued Events

Sending out emails or notifications can drastically slow down a users experience. Take for example, when adding a comment. Having the user wait around for an email to be sent out to all the users that need to be notified can take time. To assure this does not happen, apps can trigger queued events to be executed at a later time.

Queues are internally stored in Redis and can be picked up via Cronjobs or triggered via our web socket routine.

Git

PHPfox is based on an open source social framework we have developed that provides the base functionality of a social networking platform for SaaS. Any additional feature PHPfox provides will be developed as an app, and clients will then be able to update each app instead of the entire core comfortably at their convenience.

The core will be available on GitHub and this opens the door for developers to download the core so they can develop apps for our client base without the need to getting a license and access to all the extra functionality that isn't needed to develop apps.

Since the core will be on Git, clients can clone or fork the core and easily apply updates as they come, without the need to download the entire ZIP package. For those that want to extend the core, can fork the project and keep their changes/additions to the product when we push updates.

Requirements

v4 requires PHP 5.4 or higher. You will need to have access to Redis, note while we will only work with Redis as our primary database it is built as a driver and the core can have other drivers, such as using MySQL, which if time permits we will develop. Although to fully utilize the major improvements to the stream, Redis is your best choice.

Our messenger system uses Web Sockets and requires access to the server to run the PHP event loop. While our first choice was to use NodeJS with Socket.io, we wanted to stick with PHP so we could use our base framework to allow developers to safely use Web Sockets with their apps.

Save the dates - PHPfox ETA

An RC1 Release Date has been established and is estimated to be March 4th, 2015. This date is an ETA and is subject to be changed; however, we're doing our best to make sure to meet this deadline.