Jump to content

Richard Jedlička

Members
  • Posts

    86
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Richard Jedlička

  1. I didn't read the whole topic, so hope I guess corretly what is it about. I add my approach to having different configs for each environment. I did it very simple, just used environment variables, so I have one configurable config for all 🙂

    (I am using docker on localhost so it is easy to work with environment variables)

    <?php namespace ProcessWire;
    
    /**
     * ProcessWire Configuration File
     *
     * Site-specific configuration for ProcessWire
     *
     * Please see the file /wire/config.php which contains all configuration options you may
     * specify here. Simply copy any of the configuration options from that file and paste
     * them into this file in order to modify them.
     *
     * SECURITY NOTICE
     * In non-dedicated environments, you should lock down the permissions of this file so
     * that it cannot be seen by other users on the system. For more information, please
     * see the config.php section at: https://processwire.com/docs/security/file-permissions/
     *
     * This file is licensed under the MIT license
     * https://processwire.com/about/license/mit/
     *
     * ProcessWire 3.x, Copyright 2019 by Ryan Cramer
     * https://processwire.com
     *
     */
    
    if(!defined("PROCESSWIRE")) die();
    
    /*** SITE CONFIG *************************************************************************/
    
    /** @var Config $config */
    
    /**
     * Allow core API variables to also be accessed as functions?
     *
     * Recommended. This enables API varibles like $pages to also be accessed as pages(),
     * as an example. And so on for most other core variables.
     *
     * Benefits are better type hinting, always in scope, and potentially shorter API calls.
     * See the file /wire/core/FunctionsAPI.php for details on these functions.
     *
     * @var bool
     *
     */
    $config->useFunctionsAPI = true;
    
    
    /*** INSTALLER CONFIG ********************************************************************/
    
    
    /**
     * Installer: Database Configuration
     *
     */
    $config->dbHost = getenv("DB_HOST");
    $config->dbName = getenv("DB_NAME");
    $config->dbUser = getenv("DB_USER");
    $config->dbPass = getenv("DB_PASS");
    $config->dbPort = getenv("DB_PORT");
    $config->dbEngine = 'InnoDB';
    
    /**
     * Installer: User Authentication Salt
     *
     * This value was randomly generated for your system on 2021/12/14.
     * This should be kept as private as a password and never stored in the database.
     * Must be retained if you migrate your site from one server to another.
     * Do not change this value, or user passwords will no longer work.
     *
     */
    $config->userAuthSalt = getenv("USER_AUTH_SALT");
    
    /**
     * Installer: Table Salt (General Purpose)
     *
     * Use this rather than userAuthSalt when a hashing salt is needed for non user
     * authentication purposes. Like with userAuthSalt, you should never change
     * this value or it may break internal system comparisons that use it.
     *
     */
    $config->tableSalt = getenv("TABLE_SALT");
    
    /**
     * Installer: File Permission Configuration
     *
     */
    $config->chmodDir = '0755'; // permission for directories created by ProcessWire
    $config->chmodFile = '0644'; // permission for files created by ProcessWire
    
    /**
     * Installer: Time zone setting
     *
     */
    $config->timezone = 'Europe/Prague';
    
    /**
     * Installer: Admin theme
     *
     */
    $config->defaultAdminTheme = 'AdminThemeUikit';
    
    /**
     * Installer: Unix timestamp of date/time installed
     *
     * This is used to detect which when certain behaviors must be backwards compatible.
     * Please leave this value as-is.
     *
     */
    $config->installed = 1639521804;
    
    
    /**
     * Installer: HTTP Hosts Whitelist
     *
     */
    $config->httpHosts = preg_split('/\s*,\s*/', getenv('HTTP_HOSTS'));
    
    
    /**
     * Installer: Debug mode?
     *
     * When debug mode is true, errors and exceptions are visible.
     * When false, they are not visible except to superuser and in logs.
     * Should be true for development sites and false for live/production sites.
     *
     */
    $config->debug = filter_var(getenv("DEBUG"), FILTER_VALIDATE_BOOLEAN);
    
    $config->advanced = true;
    

     

    • Like 2
  2. Hi there,
    I have a PW website which I want to use as a CMS. I will have also some different scraper application which will retrieve data from the web and needs to store them in that PW website as pages. The problem is, it will be in JS not PHP and will be on different server (but with access to the PW's server). One thing to consider is the scraper will generate a lot of data.

    I am thinking about the best solution to this, I have some ideas:

    1) Create a REST api in CMS and let the scraper send request over HTTP
    2) Use websockets
    3) Install another PW instance along with the scraper with the access to the same database as CMS and call it over command line.
    4) Insert data from scraper directly to the database (create pages)

    What approach do you think is the best. I want to have CMS UI usable while the scraper sends many requests (multiple per second).

    I am interested in the option 3) but not sure if PW support that, running multiple instances with the same database.

    Thanks

  3. Hi I created new module for adding links to quickly edit a field directly from page edit. 

    https://processwire.com/modules/admin-helper-links/

    admin-helper-links.thumb.png.3220f23c38da003c6ed4b4b5d063c460.png

    You probably already know existing module HelperFieldLinks created by @Soma which was my inspiration. I was using that module for a long time so thank you @Soma! The reasons for this new module are that HelperFieldLinks seems inactive and contains few bugs. I decided to try to fix them, but after a short time I realized a better (i think) and simpler solution and also got some new ideas how to improve. I used javascript instead of PHP and modified a code which is already in PW source code to show field names when you hover the inputfield's expand arrow (in debug mode). I also moved the cog icon next to the expand icons which doen't break the layout so much. What is missing is the field info panel with it's props, never used it, but it can be done too. The template edit links needs to be added too. 

    If you got some ideas how to improve, tell me.

    • Like 10
    • Thanks 1
  4. Hi, in my project one page has a text field with a regext pattern. The field accepts signed (+/-) number and can contain spaces between digits. I would like to remove the spaces after the form is submitted. What is the good approach to do that? I have few ideas:

    1. Leave it be as it is and format the value on output. ☹️
    2. Create new fieltype/inputfield with this funcionality. 😣
    3. Hook processInput method of the Inputfield and remove the spaces. 😁

    I would prefer the 3. option.

    But what about if I want to have it configurable (to remove spaces or more complex stuff), without creating new fieldtype/inputfield? Is it good to hook getConfigInputfields method? Is it enought to just append some input for it or do I have do some more logic somewhere?

    What would be your approach, and are there some other modules extending fieldtypes and inputfield the similar way?

    Thanks

  5. @bernhard I found a bug in your RM update, this line https://github.com/BernhardBaumrock/RockMigrations/blob/master/RockMigrations.module.php#L1007 should be

    $data[$key] = $addFields;

    Data under repeaterFields option should be field ids, not names, obviously. Otherwise style and script assets are not loaded for inputfields in repeater (if not present in other places in the form). It took me quite a long time to figure out that 😅.

    • Like 1
    • Thanks 1
  6. 1 hour ago, bernhard said:

    When I started with RockMigrations I had a setup similar to other migration modules where every migration was its own file and had an upgrade() and downgrade() method. I also had methods to check whether a migration should run or not (version compare). But that was a pain to work with, so over time the declarative syntax won. I agree that sometimes it would be nice to have the option to run migrations only for some versions of the project, but I have not had a good idea how to achieve that yet...

    Ok, I will try to live with that and in case of necessity I will try to find a solution.

  7. 3 hours ago, bernhard said:

    Adding data via migrations is the most straightforward thing, but removing or renaming is a little more tricky, as you realized 🙂 Usually all methods are built in a way that they can run as often as you want. That means you can just run $rm->renameField(...) as often as you want: https://github.com/BernhardBaumrock/RockMigrations/blob/dc9dba1b050469ea085af9dca1201746e2422960/RockMigrations.module.php#L942-L944

    I know that adds a little overhead and I've heard from @dotnetic that some of his migrations needed around 20 seconds to finish. On all of my setups (and I'm using RM all the time, everywhere, extensively) site-wide migrations fired via $rm->fireOnRefresh(...) take at most around 2 seconds to finish.

    So you think I just have to make the code independent of how many time it ran? My reasoning wan't about it is time consuming but about it will do some changes which cannot be run more time, like some data migrations, which means I have somehow determine I was done before.

     

  8. @bernhard Some questions come to my mind. 

    1) I am now using $rm->fireOnRefresh(...) for executing my "permanent" migrations (mostly declarative, describing a structure). But what should I do if I have some migration which I want to run only once, e.g. renaming a field (but could be more complex dealing with data). I got an idea to run that specific "upgrade" migration when upgrading a module to a specific version, which would work. The problem is, when I refresh modules my "permanent" migrations (which expects the field is already renamed!!) will run before upgrading a module and running the "upgrade" migration. 🤔

    2) Did you explored the Import/Export code (for fields, templates, ...) already built in ProcessWire? It is similar to what RockMigrations do (in declarative way) or not? I did not explored it much, but I am thinking if your module is needed, if there are already similar functions in a core code.

    3) Consireding 2) and previous discussion

    On 12/8/2021 at 4:19 PM, bernhard said:

    At the moment not, but if you think that would be worth to have you could add that here and create a PR: https://github.com/BernhardBaumrock/RockMigrations/blob/dc9dba1b050469ea085af9dca1201746e2422960/RockMigrations.module.php#L984-L990

    when I export a template or repeater field (using the built-in admin buttons), context for subfields is stored under fieldContexts key, so e.g. for a repeater field:

    'repeater_field' => [
    	'type' => 'repeater',
    	'label' => 'Label',
    	'repeaterFields' => [
    		'field1',
    		'field2'
    	],
    	'fieldContexts' => [
    		'field1' => [
    			'columnWidth' => 50
    		],
    		'field2' => [
    			'columnWidth' => 50
    		]
    	]
    ]

    the same for a template, so maybe you can use the same format in RM.

  9. Hi @bernhard, thank you for this great module. I am trying to add a repeater field which is very easy as this 

    'repeater_field' => [
    	'type' => 'repeater',
    	'label' => 'Label',
    	'repeaterFields' => [
    		'field1',
    		'field2'
    	]
    ]

    How can I set fields' contexts, I need to set their columnWidths

    I tried the same approach as with template fields

    'repeater_field' => [
    	'type' => 'repeater',
    	'label' => 'Label',
    	'repeaterFields' => [
    		'field1' => [
    			'columnWidth' => 50
    		],
    		'field2' => [
    			'columnWidth' => 50
    		]
    	]
    ]

    but it doesn't work.

×
×
  • Create New...