fuelphp-storage / fuelphp Goto Github PK

This package will contain the code generation (scaffolding) code of the 1.x Oil package.

It should have a pluggable architecture, so that external components can add extra features to it. For example the ORM package could provide the generators for ORM models.

oil g scaffold foo status:enum[pending, cancelled, active, complete]

Error: One or more fields were badly specified. Ensure they are name:type

It appears support for enum has been removed in 1.5?

The current Asset class will be replaced by the Assetic package (https://github.com/kriswallsmith/assetic). An integration class needs to be provided to have this package integrate into the framework.

Can probably be taken as-is from v1, and placed in the Common package.

Both classes need to be reviewed, as there is a bit over overlap between the two, and in essence all Inflector methods are actually string handling methods...

Generic class to convert data formats.

I would like to know if the 2.0 version development is active. This Repo is updated 2 months ago.

I am looking for a way to track the development of v2.0

For FuelPHP 2.0, the current Redis class will be dropped, and replaced by the Predis composer package.

In the compatibility package, we need to provide the API translation between the two.

Needs to be a wrapper for MonoLog, probably in Foundation since it's used everywhere.

We need a new profiler.

The 1.x version, which was based on PHPQuickProfiler, is no longer maintained, and it's code is complex and messy. It also lacks functionality, particularly when it comes to debugging REST API's.

The new package needs a structure not unlike Monolog. With a central logger class, a pluggable architecture for message types which unify the input to a standard internal type, a flexible message group system so messages can be grouped, and output renderers that can send the messages to a specific destination.

For both message types and renderers an interface or abstract class must be defined to type hints can be used and the presence of the correct methods is guaranteed. Renderers may be capable of outputting a message in realtime, buffer them until they are triggered, or both.

Related to #9.

In addition to current functionality, it needs

• a better sequencing mechanism then just numbers in a filename
• dependency management
• PSR compliant class names
• a mechanism that prevents folder sweeps when looking for migrations
• the option for a single migration to abort an entire migration run
• the option for a single migration to abort the current run
• the option for a single migration to skip itself (so it will run again on a next migration run)

Hello,

We're having some problems in our implementation of a site written in the framework when moving it to a new platform with high availability web servers.

The current way of storing the config files as text based arrays (php,json,etc) on the file-system is causing us problems with replication, in the sense that we'd have to use rsync to keep all the nodes up-to-date and we could only run the scripts that make changes to those config files on one node to make that the master, eliminating a part of our high availability.

We've had a long discussion in-house and decided the best way to go about this would be to store the values in a database - this may involve a lot of selects rather than disk reads, but in our environment our database access is a lot less expensive than disk access.

Just to float the question out there, we were debating if we should extend the class ourselves just as part of our app, or would anyone find it beneficial if we fork, edit the Config class and submit the changes?

Does anyone have any comments?

Regards,
iamacarpet

The functionality of the existing class can be converted as-is to non-static methods.

If probably need to be less dependent on the existence of the browscap file, since the availability seems not to be guaranteed these days.

The current Oil package has to be split into a separate Cli package, a "commandline control" engine capable of running tasks, a separate Code generation package that deals with scaffolding, and an Admin generation package, that can generate a generic admin backend.

I was trying the latest fuelphp version and I wanted to see if the 404 page had the same fancy look (congratulations for that by the way) as the other error pages...
And instead of an exception related to the router or just a page saying the good old "404 - Not Found" I got "Could not resolve: Fuel\Foundation\Response\ %Really_long_html_code_here_in_the_middle_of_the_title_that_looks_like_the_code_for_the_404_error_page%".

Just pointing it out to make sure that all the bugs are reported as soon as possible to release the new FuelPHP as soon as possible!

I was extend this method in my code. It check that 2d array must only have these key.

    /**
     * The haveOnlyKey2D is method checks if haystack array passed is 2 dimension array and all key match to the needle. If there are another keys in haystack, it will return false.
     * 
     * @param mixed $needle The searched value. This can be string, integer, or array.
     * @param array $haystack The array to check.
     * @return boolean Only all key in haystack match needle will be return true.
     */
    public static function haveOnlyKey2D($needle, array $haystack)
    {
        // is haystack is multi dimension array?
        if (\Arr::is_multi($haystack)) {
            return false;
        }

        $number_not_in_needle = 0;

        foreach ($haystack as $key => $item) {
            if (is_array($needle)) {
                // needle is array.
                if (!in_array($key, $needle)) {
                    $number_not_in_needle++;
                }
            } else {
                // needle is NOT array.
                if ($needle != $key) {
                    $number_not_in_needle++;
                }
            }
        }

        if ($number_not_in_needle == 0) {
            return true;
        }

        // not in conditions above.
        return false;
    }

example:

$_GET['cid']; $_GET['page']; $_GET['filter'];
\Arr::haveOnlyKey2D(array('cid', 'page'), $_GET); // return false.

$_GET['cid']; $_GET['page'];
\Arr::haveOnlyKey2D(array('cid', 'page'), $_GET); // return true.

$_GET['cid'];
\Arr::haveOnlyKey2D(array('cid', 'page'), $_GET); // return true.

I didn't found the composer package "fuelphp/fuelphp" (as defined in composer.json), it would be easier to include and to test if it was included in packagist.org.

I think FuelPHP needs a separate security package, that will contain all classes and method related to security:

• Crypt
• Validation and cleaning
• CSRF protection
• PHPSecLib

There is a composer package for PHPSecLib. Biggest problem is that it's loaded with trigger_error()/user_error() calls instead of exceptions, which kinda sucks...

There is already some security code in the Foundation package, this will have to move too. This also means there won't be a need for a separate Crypt package.

I just wanted to try it...

public/index.php: $env = FuelPHP::resolve('Environment')->init

Fatal error:  Uncaught exception 'FuelPHP\DependencyInjection\ResolveException' with message 'Could not resolve, unexpected output output: Environment' in fuelphp/vendor/fuelphp/dependency-injection/src/FuelPHP/DependencyInjection/Resolver.php:193
Stack trace:
#0 fuelphp/vendor/fuelphp/dependency-injection/src/FuelPHP/DependencyInjection/Resolver.php(153): FuelPHP\DependencyInjection\Resolver->formatOutput('Environment', Array)
#1 fuelphp/vendor/fuelphp/dependency-injection/src/FuelPHP/DependencyInjection/Container.php(77): FuelPHP\DependencyInjection\Resolver->resolve('Environment', NULL, Array)
#2 fuelphp/vendor/fuelphp/dependency-injection/src/FuelPHP/DependencyInjection/Container.php(42): FuelPHP\DependencyInjection\Container->resolveEntry('Environment', NULL, Array)
#3 [internal function]: FuelPHP\DependencyInjection\Container->resolve('Environment')
#4 fuelphp/vendor/fuelphp/foundation/src/FuelPHP/Foundation/FuelPHP.php(100 in fuelphp/vendor/fuelphp/dependency-injection/src/FuelPHP/DependencyInjection/Resolver.php on line 193

UPDATE
FuelPHP::register('Environment', 'Environment'... is called in fuelphp/vendor/fuelphp/foundation/src/kickstart.php

Convert the 1.x Auth package to 2.0.

Functionality can be copied from the 1.x class.

Since Cookie is an application context class, and in the future multiple applications will be supported, it might not be a bad idea to make the class application aware.

It will allow the class to make cookies application specific (for example by prefixing the cookie name with the application name).

Or use an existing Cli package as the basis, and add a Fuel wrapper to it if needed.

Implement http://filp.github.io/whoops/demo/ for nice informative error reporting.

The foundation package currently has the beginnings of the default base controller. This needs to be finished, and the other base controllers need to be added.

The design needs to be reviewed to get rid of the current kludge that is the hybrid controller.

Can be taken largely as-is from 1.x.

Or pick and existing package, and write a wrapper class?

Class to communicate with FTP servers.

I've been encountering an issue whereby any fatal errors that occur during execution are not displayed to the browser. In fact nothing is sent to the browser and it displays 324(net:ERR_EMPTY_RESPONSE). This happens across all browsers, it is not a browser issue.

This problem only surfaces on Mac OS X (I'm using Apache installed through XAMPP). When running the code on Windows or multiple Linux servers I get the correct output of the fatal error, displayed through the pretty Fuel error output page.

I can reproduce the issue by:

-Installing fresh copy of XAMPP on Mac OS X
-Installing fresh copy of Fuel 1.5.3
-In the action_index() of the welcome controller, placing a random PHP line with no semi-colon at the end (thus generating a fatal parse error)

I tried tracing the problem, and I got down to the register_shutdown_function() in fuel/core/bootstrap.php

If I exit() at the top of that function, or comment the whole function out completely, then the fatal error is outputted to the browser (sans Fuel's pretty error output display). I'm guessing that something is going wrong after that point (it goes on to call the Event class and the Error class) and because the code has already entered the shutdown function, the error is not outputting.

I tried repeating the same steps as above with Fuel 1.4 and the issue did NOT occur (i.e. the fatal error WAS shown as expected). The fact that Fuel 1.4 does not have a register_shutdown_function in its core bootstrap might be relevant?

I'm fairly certain this is a server configuration issue. As I stated, I can reproduce the error with fresh installs of the server and the Fuel code. But it's a problem because a) I can't find WHAT server config is causing the issue and b) it's the default server config on XAMPP on a Mac which I presume is a widely used setup.

As proof that I'm not the only one having this issue, this questioner seems to be encountering the same issue (not sure if he's using XAMPP, but he is using Mac OS):

http://stackoverflow.com/questions/12587680/php-error-handling-has-disappeared-since-upgrading-to-mountain-lion

I also posted an answer on that page which details a really hacky workaround solution that I came up with for this issue until I find out what the root cause is.

I recommend someone with more experience of PHP and the Fuel core code looks at this issue because I've got to the end of my talents in so far as identifying this issue.

This is a bit of an orphan in the 1.x version, but it works, and comes in handy when you have an application that has downloadable and installable components.

Not sure yet if we need to port the existing code, or find an alternative? Open for suggestions...

I'm not convinced the 1.x Image class should stay. It's part voodoo, it's part a coding mess, and nobody knows exactly how it works, which makes maintaining difficult.

Perhaps we should drop it, and suggest http://imagine.readthedocs.org/en/latest/ instead. There's a composer package for it. Not sure it's possible to create a 1.x compatibility class for it, and not sure either it covers all functionality.

I'm open to ideas!

Bootstrap bundle requires master branches while foundation requires develop.

- Installation request for fuelphp/foundation dev-develop -> satisfiable by fuelphp/foundation[dev-develop].
- Can only install one of: fuelphp/alias[dev-master, dev-develop].
- fuelphp/foundation dev-develop requires fuelphp/alias dev-develop -> satisfiable by fuelphp/alias[dev-develop].
- Installation request for fuelphp/alias dev-master -> satisfiable by fuelphp/alias[dev-master].

What do you think to adding soft delete and restore functionality to Model Crud like in ORM.

I think it would be good to keep delete() method to actually delete a record. Instead add the method soft_delete() to perform the action.

This package will contain the code generation (admin) code of the 1.x Oil package.

It should be extended into providing a complete admin backend interface, that could be plugged into any application with minimal effort.

For FuelPHP 2.0, the current Mongo_DB class will be dropped, and replaced by FrenkyNet's Monga package.

In the compatibility package, we need to provide the API translation between the two.

The current Cache classes need to be refactored into a separate Cache package. We need to keep an eye on what FIG is doing, but compatibility is for me not mandatory.

The Crypt package should require PHPSecLib, and provide a Fuel wrapper class for it.

v1.x has two base models in the core: Model (which is an empty class), and Model_Crud.

Perhaps we should dump the empty class (what is the point of it being there?), and use Model_Crud as the base model provided by the framework.

The base model(s) must be part of the Foundation package.

Functionality can stay as-is, Model interface might change, and the DB layer needs to be swapped for the new DBAL.

Needs to be converted to dynamic methods, and added to the Common package.

It's functionality has to be reviewed, it currently missing for example date arithmetic operations...

Helper class that could be transferred as is, probably to the Common package. Its static interface should stay.

It currently has a dependency to Inflector that has to be looked at.

Containing View, Presenter, Asset, Theme and Parser, packaged into a single library. It can then be included for those creating "standard" websites, while those creating API backends don't need to have it installed.

Is dependant on #3

Needs to be rewritten for 2.0, and added to the Foundation package.

The idea is to be able to have a "match many" parameter when defining routes. This would allow the ability to pass any number of segments as an array to an action.

Example:
Define a route to match controller/action/names/[]/foo/bar where the [] would be a place-holder marker that matches any number of segments until the one after it is matched (in this case foo).

This would then be passed to the action like so:

public function action_action($names, $foo, $bar){}

$names would then be an array populated with anything that is found between the names and foo segment, or an empty array if none where matched.

A route such as controller/action/names/tom/dick/harry/foo/bar would pass the parameters below to the action.

$names = array('tom', 'dick', 'harry');
$foo = 'foo';
$bar = 'bar';

This could then also work with multiple array segments: controller/action/names/[]/ages/[] to pass multiple arrays to the action.

I'm not sure if this is the appropriate place to put this.
If desired I could create a pull request, or it can just remain as it's own separate repository..
I created a CRUD fuelphp controller.

Here's the repo: https://github.com/RyanDawkins/fuel-crud-controller

This package can contain the current 1.x FTP class, and also provide interfaces to PHPSecLib's SFTP and SSH functionality.