Jump to content

Search the Community

Showing results for tags 'composer'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Product Groups

  • Form Builder
  • ProFields
  • ProCache
  • ProMailer
  • ProDrafts
  • ListerPro
  • ProDevTools
  • Likes
  • Custom Development

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 6 results

  1. I've been working with ProcessWire for a while now, and I've noticed that using Composer to manage dependencies and autoload external libraries isn't as prevalent in ProcessWire development as in other areas of PHP programming. I started out by using the default setup recommend in this blogpost. However, one major problem I have with this approach is that all external dependencies live in the webroot (the directory the server points to), which is unfavourable from a security standpoint and, in my opinion, just feels a bit messy. In this tutorial, I want to go through a quick setup of Composer and ProcessWire that keeps the dependencies, all custom-written code and other source material outside of the webroot, and makes full usage of the Composer autoloader. This setup is pretty basic, so this tutorial is probably more useful to beginners (this is why I'll also include some general information on Composer), but hopefully everyone can take something away from this for their personal workflow. Site structure after setup This is what the directory structure can look like after the setup: . ├── composer.json ├── composer.lock ├── node_modules │ └── ... ├── public │ ├── index.php │ ├── site │ ├── wire │ └── ... ├── packacke-lock.json ├── package.json ├── sass │ ├── main.scss │ ├── _variables.scss │ └── ... ├── src │ ├── ContentBag.php │ └── ... └── vendor ├── autoload.php ├── composer ├── league ├── symfony └── ... As mentioned, the main point of this setup is to keep all external libraries, all other custom source code and resources out of the webroot. That includes Composer's vendor folder, your node_modules and JavaScript source folder if you are compiling JavaScript with webpack or something similar and including external scripts via NPM, or your CSS preprocessor files if you are using SASS or LESS. In this setup, the public directory acts as the webroot (the directory that is used as the entry point by the server, DocumentRoot in the Apache configuration). So all other files and directories in the mysite folder aren't accessible over the web, even if something goes wrong. One caveat of this setup is that it's not possible to install ProcessWire modules through Composer using the PW Module Installer (see Blogpost above), but that's just a minor inconvenience in my experience. Installation You'll need to have composer installed on your system for this. Installation guides can be found on getcomposer.org. First, open up your shell and navigate to the mysite folder. $ cd /path/to/mysite/ Now, we'll initialize a new Composer project: $ composer init The CLI will ask some questions about your projects. Some hints if you are unsure how to answer the prompts: Package names are in the format <vendor>/<project>, where vendor is your developer handle. I use my Github account, so I'll put moritzlost/mysite (all lowercase). Project type is project if you are creating a website. Author should be in the format Name <email>. Minimum Stability: I prefer stable, this way you only get stable versions of dependencies. License will be proprietary unless you plan on sharing your code under a FOSS license. Answer no to the interactive dependencies prompts. This creates the composer.json file, which will be used to keep track of your dependencies. For now, you only need to run the composer install command to initialize the vendor directory and the autoloader: $ composer install Now it's time to download and install ProcessWire into the public directory: $ git clone https://github.com/processwire/processwire public If you don't use git, you can also download ProcessWire manually. I like to clean up the directory after that: $ cd public $ rm -r .git .gitattributes .gitignore CONTRIBUTING.md LICENSE.TXT README.md Now, setup your development server to point to the /path/to/mysite/public/ directory (mind the public/ at the end!) and install ProcessWire normally. Including & using the autoloader With ProcessWire installed, we need to include the composer autoloader. If you check ProcessWire's index.php file, you'll see that it tries to include the autoloader if present. However, this assumes the vendor folder is inside the webroot, so it won't work in our case. One good place to include the autoloader is using a site hook file. We need the autoloader as early as possible, so we'll use init.php: EDIT: As @horst pointed out, it's much better to put this code inside the config.php file instead, as the autoloader will be included much earlier: // public/site/config.php <?php namespace Processwire; require '../../vendor/autoload.php'; The following also doesn't apply when including the autoloader in the config-file. This has one caveat: Since this file is executed by ProcessWire after all modules had their init methods called, the autoloader will not be available in those. I haven't come across a case where I needed it this early so far; however, if you really need to include the autoloader earlier than that, you could just edit the lines in the index.php file linked above to include the correct autoloader path. In this case, make sure not to overwrite this when you update the core! Now we can finally include external libraries and use them in our code without hassle! I'll give you an example. For one project, I needed to parse URLs and check some properties of the path, host et c. I could use parse_url, however that has a couple of downsides (specifically, it doesn't throw exceptions, but just fails silently). Since I didn't want to write a huge error-prone regex myself, I looked for a package that would help me out. I decided to use this URI parser, since it's included in the PHP League directory, which generally stands for high quality. First, install the dependency (from the project root, the folder your composer.json file lives in): $ composer require league/uri-parser This will download the package into your vendor directory and refresh the autoloader. Now you can just use the package in your own code, and composer will autoload the required class files: // public/site/templates/basic-page.php <?php namespace Processwire; use \League\Uri\Parser; // ... if ($url = $page->get('url')) { $parser = new Parser(); $parsed_url = $parser->parse($url); // do stuff with $parsed_url ... } Wiring up custom classes and code Another topic that I find really useful but often gets overlooked in Composer tutorials is the ability to wire up your own namespace to a folder. So if you want to write some object-oriented code outside of your template files, this gives you an easy way to autoload those using Composer as well. If you look at the tree above, you'll see there's a src/ directory inside the project root, and a ContentBag.php file inside. I want to connect classes in this directory with a custom namespace to be able to have them autoloaded when I use them in my templates. To do this, you need to edit your composer.json file: { "name": "moritzlost/mysite", "type": "project", "license": "proprietary", "authors": [ { "name": "Moritz L'Hoest", "email": "info@herebedragons.world" } ], "minimum-stability": "stable", "require": {}, "autoload": { "psr-4": { "MoritzLost\\MySite\\": "src/" } } } Most of this stuff was added during initialization, for now take note of the autoload information. The syntax is a bit tricky, since you have to escape the namespace seperator (backslash) with another backslash (see the documentation for more information). Also note the PSR-4 key, since that's the standard I use to namespace my classes. The line "MoritzLost\\MySite\\": "src/" tells Composer to look for classes under the namespace \MoritzLost\MySite\ in the src/ directory in my project root. After adding the autoload information, you have to tell composer to refresh the autoloader information: $ composer dump-autoload Now I'm ready to use my classes in my templates. So, if I have this file: // src/ContentBag.php <?php namespace MoritzLost\MySite; class ContentBag { // class stuff } I can now use the ContentBag class freely in my templates without having to include those files manually: // public/site/templates/home.php <?php namespace Processwire; use MoritzLost\MySite\ContentBag; $contentbag = new ContentBag(); // do stuff with contentbag ... Awesome! By the way, in PSR-4, sub-namespaces correspond to folders, so I can put the class MoritzLost\MySite\Stuff\SomeStuff in src/Stuff/SomeStuff.php and it will get autoloaded as well. If you have a lot of classes, you can group them this way. Conclusion With this setup, you are following secure practices and have much flexibility over what you want to include in your project. For example, you can just as well initialize a JavaScript project by typing npm init in the project root. You can also start tracking the source code of your project inside your src/ directory independently of the ProcessWire installation. All in all, you have good seperation of concerns between ProcessWire, external dependencies, your templates and your OOP-code, as well as another level of security should your Server or CGI-handler ever go AWOL. You can also build upon this approach. For example, it's good practice to keep credentials for your database outside the webroot. So you could modify the public/site/config.php file to include a config or .env file in your project root and read the database credentials from there. Anyway, that's the setup I came up with. I'm sure it's not perfect yet; also this tutorial is probably missing some information or isn't detailed enough in some areas depending on your level of experience. Feel free to ask for clarification, and to point out the things I got wrong. I like to learn as well Thanks for making it all the way to the bottom. Cheers!
  2. Hi everyone, I can't get my head around this, so maybe someone can help: I want to know how install the dev branch of processwire with composer. I use laragon and the "quick create" function and there you can run composer like this: "composer create-project processwire/processwire %s". OK, this is working, so I will get the master branch from it, but how about dev? I found some examples for laravel on this question, but no luck with it. Here some examples: composer create-project processwire/processwire %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev %s composer create-project processwire/processwire:dev %s --stability=dev composer create-project processwire/processwire:dev %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev-master %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev-branch %s --prefer-dist --stability=dev composer create-project processwire/processwire:@dev %s --prefer-dist --stability=dev and so on... Maybe someone got this already and would like to share?
  3. Howdy, i was just wondering if there is already workaround in core that would automatically sniff for composer.json up on module installation and install dependencies? What i'm currently doing is that i include vendor folder into modules, but somehow this feels stupid as of core could just handle this part up on module installation and place dependencies under ROOT_PATH/vendor/? i tried quickly to look around for previous posts about this topic, but couldn't find anything. Cheers!
  4. I'm developing a module to integrate BigCommerce's Stores API (https://developer.bigcommerce.com/api) with PW. After a steep learning curve, I managed to use composer.json to download the latest version of the API into a 'vendor' directory. { "name": "processwire/processwire", "type": "library", "description": "ProcessWire CMS/CMF", "keywords": [ "cms","cmf", "content management system" ], "homepage": "https://processwire.com", "authors": [ { "name": "Ryan Cramer", "email": "ryan@processwire.com", "homepage": "https://processwire.com", "role": "Developer" } ], "require": { "php": ">=5.3.8", "ext-gd": "*", "bigcommerce/api": "*" }, "autoload": { "files": [ "wire/core/ProcessWire.php" ] }, "minimum-stability": "dev" } Using composer.json and its autoload.php feature works great. All I need in my template is: <?php use Bigcommerce\Api\Client as Bigcommerce; Bigcommerce::configure(array( 'store_url' => 'https://www.mybigcommerceshop.com', 'username' => 'admin@mybigcommerceshop.com', 'api_key' => '8fab84ce1776dbba18665xxxxxxxxxxxxf' )); $ping = Bigcommerce::getTime(); if ($ping) echo $ping->format('H:i:s'); My dilemma is that the files are in './vendor', not './site/modules'. Not everyone will use composer.json so looking for recommendations on how to best code the module to first look in './vendor', then if nothing there, look into './site/modules/BigCommerceApi/Api' to load the files (which may be out of date) and instantiate the API. Suggestions? Using: PW v3.0.24
  5. Hello, PW 3 uses namespaces and Composer. I wanted to include https://github.com/vlucas/phpdotenv for having a nice .env file with all my DB settings. On 2.7 I simply included everything in the top of the index.php: // Custom require __DIR__ . '/vendor/autoload.php'; $dotenv = new Dotenv\Dotenv(__DIR__); $dotenv->load(); Now, composer is there so I used "composer require vlucas/phpdotenv" and wanted to use it. The current index.php includes the autoloader via: $composerAutoloader = $rootPath . '/vendor/autoload.php'; // composer autoloader if(file_exists($composerAutoloader)) require_once($composerAutoloader); So after that, I tried to add: // Custom $dotenv = new Dotenv\Dotenv(__DIR__); $dotenv->load(); but the error is: Fatal error: Class 'ProcessWire\Dotenv\Dotenv' not found in /var/www/index.php on line 36 It's because on top of the index, there is <?php namespace ProcessWire; So Dotenv is interpreted like a child of ProcessWire. How can I change this? If interesting, here is my composer.json: { "name": "processwire/processwire", "type": "library", "description": "ProcessWire CMS/CMF", "keywords": [ "cms","cmf", "content management system" ], "homepage": "https://processwire.com", "authors": [ { "name": "Ryan Cramer", "email": "ryan@processwire.com", "homepage": "https://processwire.com", "role": "Developer" } ], "require": { "php": ">=5.3.8", "ext-gd": "*", "vlucas/phpdotenv": "^2.2" }, "autoload": { "files": [ "wire/core/ProcessWire.php" ] } } Thanks for your answers!
  6. Now that 2.3 has been finished, when will you (Ryan) start developing 2.4? According to the roadmap 2.4 will port the hole system to PHP 5.3+ which I think is great. It says we'll get namespaces, PSR-0 and PSR-1 support. What exactly does it mean? Will it use Composer? I really think it should as it's the greatest asset for the future of PHP. We could keep the framework seperate so that others can use it (http://processwire.com/talk/topic/818-currentformer-textpattern-users-what-do-you-think-txp5-using-pw/). I'd also like if PW used some proved libraries from (for example) Symfony (http://symfony.com/components) or Laravel (http://github.com/illuminate). Maybe because I'd love a "Processwire on Laravel (Components) with Craft-like design" Just interested in how Ryan is going to make PW adopt 5.3, PSR + Composer will push PHP in the future and there are great libraries that are well (unit-)tested and could be used.
×
×
  • Create New...