usbac / wolff Goto Github PK

I have been wanting to install Wolff via composer with no avail.
I tried the following in command line:
composer require Wolff
The command to install should be in the Wiki pages, I suggest.

Find below is a screenshot explaining the issue in details:

I noticed that the framework does not have any tests written. Would be good if some tests could be made in order to ensure that any new updates didn't break older features.

Great work so far! Really small codebase given the current features.

Hello, and thanks for such a simple tool to work with.

I was wondering, since main framework does not have any 3rd-party dependencies included, does it have to stay like that in future? I planned some PRs, so I am asking.

Thanks 👍

I tried running the command composer create-project usbac/wolff but it doesn't create the vendor folder.
It's so annoying

The previous version had the route parameter working fine for me, not this one.

When adding a parameter in the Routes.php file,

Route::add('main_page/{username}', function (){

/*
This route is ignored and it loads the 404 page.
*/

});

If the parameter is added without the 'main_page', it throws a fatal error.
For example

Route::add('/{username}', function (){

/*
This route will throw a fatal error.
*/

});

I like your framework. It is small & fast. I would like to fix a cli command issue given below:

$ php Wolffie mk route page pages/contact
PHP Warning:  fopen(System/definitions/Routes.php): failed to open stream: No such file or directory in /var/www/html/samples/php/wolff/system/cli/Create.php on line 226

On line 19 in system/cli/Create.php, folder System should be system.

$this->routes_dir = 'System/definitions/Routes.php';

to

$this->routes_dir = 'system/definitions/Routes.php';

The Website
https://www.getwolff.com/
http://www.getwolff.com/
https://getwolff.com/
http://getwolff.com/
is not reachable. The missing/broken links in the documentation makes it hard to read.

I would like to compare wolff with SlimPHP. Has anyone already made and documented this comparison?

On the Controller documentation page, the "Call Controller Method" section says:

Call controller method

method(string $path, string $method[, array $args]): mixed

Returns the value of a controller method.

The first parameter must be the controller name, the second and optional parameter must be the method name, the third and optional parameter must be an array with the arguments that will be used for the method.

The function signature shows that $method is required, but the paragraph underneath mentions "the second and optional parameter". The function signature in the class Wolff\Core\Controller matches (roughly) the signature listed:

public static function method(string $path, string $method, array $args = [])

Which indicates that it's not optional.

Is the second parameter intended to be optional, or required?

Below
Creating a new view:

you wrote 'create Library' instead of
'create view'

• I wish to suggest that you add the vendor folder and any other dependencies of wolff framework in it's classic .zip download file at https://github.com/Usbac/wolff/archive/v2.6.zip

• To me, it is better so anyone who chooses to download the zip file (instead of installing via composer) will not have to run composer install to get the vendor and all dependencies.

• It will make wolff framework really easy to install and accessible to even the most beginners in PHP who don't know how to use composer.

Thanks

The framework is great! I remember back a few months when it started and I had to download the first version and use it for a project.

I will like you to implement an auth functionality similar to php artisan make:auth https://laravel.com/docs/5.7/authentication to make the developing phase faster and sweeter ;-) for developers like me.

Thanks

Hi again, I have been wondering how possible is it for you to make the template engine syntax to be valid on included PHP files also.

• For example, the home controller loads the app/views/home.php
• Suppose I include a file nav.php from the home.php view
• It would be nice if the syntax, say {{ $language['welcome'] }} be available in this nav.php included file.

Thank you

Just some thoughts...

• Global constants ( https://github.com/Usbac/Wolff/blob/master/config.php ) obviously can conflict with global constants defined by third party libraries. Yes ofcourse it is more handy to only write echo PAGE_TITLE instead of echo $this->config->get('page_title') or whatever, but I don't think having a global constant called PASSWORD is a good idea. Password of what? If you would create a separate config file for the database config and use something else than global constants it would be unique and not causing any conflicts due to ambiguity.
• The folder app/controller contains multiple controllers so why not name it app/controllers?
• It's a convention that class names always should start with an uppercase letter ( for instance Home instead of home => https://github.com/Usbac/Wolff/blob/master/app/controller/home.php#L5)
• You might consider to use type hint annotations also on class properties, for instance: /** Core\Cache */ public $cache; instead of just public $cache; ( https://github.com/Usbac/Wolff/blob/master/system/Start.php#L11 )

I think the things that I mentioned are more or less conventions. It makes it easier for other coders to read and understand code if these conventions are followed.

This framework is amazing, @Usbac

1. I suggest that files should be named according to what they do as it will be more descriptive.
   For example: home.controller.php , home.model.php and home.view.php

2. Secondly, an assets folder should be created in the app folder to contain images, css, js and other files rather than being in the views folder.

assets
-- images
-- css
-- js

Hi @Usbac I no longer see the model folder and $this->load->model() and $this->load->library() are no longer valid. These are very important aspects of the framework which makes it ridiculously simple working with databases and external libraries. I checked on the documentation but couldn't find any help. Can you please elaborate more on that? Thank you.

Hello Wolff Team,

I try to get the URI parameter in order to check a product, but the request get automatically lowercased.

This is the sample code I used:

The problem is it has to be case sensitive in order to catch the real id.
I didn't find anything in the doc.

Do you know if you can have an option to keep it case sensitive?

Thanks for your awesome job.

Regards.

Louis

for example:

public static function set($param,$value=false): void
  {
    if (is_array($param)) {
      foreach ($param as $key => $value) {
        $_SESSION[$key]=$value;
      }
    }
    else {
      $_SESSION[$param]=$value;
    }
  }

There used to be a Route::api() in previous versions which was really useful to communicate with other external services.
My question is how do we use this functionality in the recent version? and if possible can you add it to the documentation http://getwolff.com/doc/3.x/routes

Also, I really like the Container feature mentioned in the documentation https://getwolff.com/doc/3.x/container which can enable us write our own custom Classes/Libraries.
The documentation is however not explicit...like where do we store these custom class, how to call it from a controller file, etc.

Thank you

Hi, I have checked out the Framework and it is well organized and easy to understand.

What I am wondering is if there is an example project built with this framework so we can get to understand the code much better.

Thanks.

I wish to point out that on both version 1.x and 2.x installation pages, https://www.getwolff.com/doc/1.x/installation and https://www.getwolff.com/doc/2.x/installation

The commands to install Wolff via composer are all the same
composer create-project usbac/Wolff

• The question is: how do we specify the version we wish to install in the composer command?

• May be you could precise these different commands on both installation pages?

• Maybe something like composer create-project usbac/Wolff -v 1.x and
  composer create-project usbac/Wolff -v 2.x

Thank you

The Wolff project generates an Internal Server Error once installed on non-Windows servers which makes it impossible to use framework.
After troubleshooting, I figured out the issue:
/public/index.php" is writeable by group is the error thrown on linux hosting servers.

• This happens because the above mentioned file in /public/index.php has a permission of 0777 and it looks like Linux servers don't support that for some reason

• My suggestion is that you recursively change the file permission for each Wolff files (to say 0755) so this issue gets resolved in future releases.

Thank you

Good day Wolff team and it's always a pleasure writing to you.

• This time around, I recommend you give users the option to also store their views files as .wlf, .html and .php. I just had to change mine manually in the \Wolff\Core system to .html

• The main reason behind this is because .wlf files unfortunately are not yet compatible with text editors like Sublime Text, VS Code, Brackets, Atom etc..and so coding can be tudious as the text editors don't color-format .wlf files.

• One solution to this could be to create an extension ( for intellisense) for text editors to understand .wlf files but I guess it's a whole project on its own for now.

Thank you ;-)

Hi everyone. I wonder if any of you have successfully hosted a Wolff project to the production server
As for me, I get the error PHP Fatal error: Uncaught Error: Class 'System\Route' not found in /home1/.../system/routes.php:5 when I upload to a production server.

The project was actually working very wll on localhost with no PHP errors.

You made a small typo in the wiki pages. The controller should extend from Controller not Model. Keep up the good work!

https://getwolff.com/starting

I don't understand why (like a lot of other projects) databse port config is not available....

Sorry, my English is not good. -_-''

for example:

Route::get('/login', [ Controllers\User::class, 'showLoginForm' ]);
Route::post('/login', [Controllers\User::class, 'login']);

I'd like to achieve that every route within a given subdirectory should have

    $res->setHeader('Content-Type', 'application/json');

Currently I need to use setHeader for every route.

Something like this would be great; Alternatively, I am of course open for feedback how it would otherwise work.

Middleware::before('/api', function($req, $next, $res) {
    $res->setHeader('Content-Type', 'application/json');
});

(Maybe it would also be an idea that writeJson() would add this header automatically, at least via a controllable parameter?)

How to get the message after verification failure？

In addition, the home page link is wrong. https://www.getwolff.com/doc/4/home

I really do love this like this light framework and the improvements you make each day.
I use it on many projects and when cloning a new version, working and uploading to production on an online server, some errors serious errors come making me frustrated since I have to wait for you to provide a solution.

That is why I suggest you deploy the framework on production to test that everything works well, before releasing in on GitHub.

Thank you

You should consider separating system folder and app folders into separate repos. So when someone clones app, he has the framework installed with Composer and when someone wants to start a fresh project, he can include the framework with composer and start building?

Using version 3.0

Error problem after first installation
I guess it's like a cache problem
Please tell me how to solve
404
{{ $lang['msg'] }}

Hi,

I've seen your simple but amazing Wolff framework and I would like to know how to run the project on my localhost.
I'm able to use XAMPP or Vagrant Homestead for PHP projects.
Remember to upgrade your documentation ;)

Many thanks,
Keep going with your framework!

<?php

return [
    'db' => [
        'dsn'      => '',
        'username' => '',
        'password' => '',
    ],

    'env' => [
        'file'     => 'system/.env',
        'override' => true,
    ],

    'language'       => 'en',

    'development_on' => true,
    'template_on'    => true,
    'cache_on'       => true,
    'stdlib_on'      => true,
    'maintenance_on' => false,
];

The maintenance page is not calling up when having maintenance_on => true in the .env file and env.override => true while maintenance_on => false in the config.php

Config::get('maintenance_on') also correctly returns true

Setting maintenance to true in the config file results in showing the maintenance page back again but it should already have been shown with maintenance_on set to true in the .env file, or not?