Jump to content

Richard Jedlička

Members
  • Content Count

    61
  • Joined

  • Last visited

  • Days Won

    1

Richard Jedlička last won the day on December 10 2016

Richard Jedlička had the most liked content!

Community Reputation

87 Excellent

About Richard Jedlička

  • Rank
    Full Member

Contact Methods

  • Website URL
    https://github.com/uiii

Profile Information

  • Gender
    Male
  • Location
    Czech Republic

Recent Profile Visitors

4,152 profile views
  1. Hi, I'm creating a custom process module with a subpages (via ___executeXXX). The problem is the module's main page uses in the breadcrumbs a module's page title but the sub pages uses a title of the module itself as a parent page in a breacrumbs, see: Modules config: public static function getModuleInfo() { return [ 'title' => 'Réva Jedlička - Kontakty', 'version' => 1, 'summary' => '', 'page' => [ 'name' => 'contacts', 'title' => 'Kontakty', ], 'requires' => [ 'Revajedlicka' ], 'installs' => [ 'RevajedlickaContactsImport' ] ]; } Breadcrumb for main page (___execute()): Breadcrumb for a subpage (___executeDetail()): What should I do to have Administrace > Kontakty > Detail there without changing the name of the module? Thanks Richard
  2. It's because, packagist automaticly creates versions of a package, so you can specify which version you want to install. Without tags you can only install dev-master version (current latest commit) which composer considers as development while tags considers as stable. With tags composer installs the latest tagged version if you don't specify any, but if there is none you have to explicitly specify dev-master if your composer json is not configured to accept it automatically. See my module https://github.com/uiii/ProcessWire-FieldtypePDF as example.
  3. Ah, good! Yes, this is also the way. But I see composer as de-facto standard for maintaining dependencies, not only PW modules. I'm used to npm in JS world and love it, so composer is the way for me. Great, thank you. One more thing you could do is to add git tag for each released version, or at least add the latest one.
  4. Thank you for quick reply! I will take a look at it. I see composer installation really useful because I've just specified all dependencies in composer.json file and don't have to commit modules into my site's source code. So, when I deploy the site to production the automated script easily install all dependecies. All I have to do manually is to install the modules via admin (maybe this could be automated as well) or refresh if they are already installed. I've even created a "wrapper" composer package for processwire (see https://github.com/uiii/processwire), which will install like a regular installation, or upgrade the existing. So my site's source code only contains the site folder (without modules) and composer.json (and composer.lock) and this is enough basis to setup the whole running site by single command: composer install
  5. Hi @bernhard, thanks for a great module. I like the migrate function for declarative definition of PW setup. 1) I saw in your example you are using ModuleName.config.php files to store the config for migration. I also saw the in other PW examples the file with the same name could be used for ConfigurableModule type of module, but as I understand it has different meaning. I know I can name the file as I want but Is it a good practice to use this file for migration (and show it in examples)? 2) Could you please add ability to set different name of directory with migrations? I'd like to use just migrations instead of RockMigrations. 3) It would be great for the module to be easily installable by composer, it is quite easy, see https://processwire.com/blog/posts/composer-google-calendars-and-processwire/#composer-for-module-developers
  6. Hi @erikvanberkum, I apologize but I don't have time to investigate it, are you able to find out what's wrong?
  7. Hi guys, I'm sorry to hear you have the issues. Unfortunatelly I don't have enough time to look at it now, I hope I'll find some in a few weeks. If you can examine it by yourself, you are welcome to send a PR. Cheers, Richard
  8. But the truth is my tool is more suitable for module or site profile development rather than for site testing, where you would test the specific PW instance.
  9. Hello there, it is good to hear that someone cares about code testing in PW community. Some time ago I've created a tool which helps you to run your tests against multiple version of PW quite easily. You can check it out there: https://github.com/uiii/tense. It is compatible with any testing framework. I would be really glad if I'm not the only one using it 🙂
  10. @ICF Church Hi, I've released new version which should fix your problem, I know it is a little bit late but if you are still interested, you may try it. I didn't face the error before but now, there are some misterious ways to me how PW detect module updates and sometimes detect the updated module as a new module so the `upgrade` method is not executed and the namespaces are not fixed which leads to the error mentioned by you. So I've moved the 'namespaces fix' code to the init method so it will check if the namespaces are fixed each time the module is initialized. It may happed that you will see the 'Fieldtype 'FieldtypePDF' does not exist' when updating the module, just hit the refresh button again and you are fine.
  11. @ICF Church One more question. Did you installed it as a new module, or updated the older version?
  12. @ICF Church Hi, I'm trying to solve your issue, but I can't reproduce the error. What version of PHP are you using? During module installation there is a step where the `use` statemenents in source files under FieldtypePDF folder are prefixed with `Processwire\' namespace if PW 3.x detected. Could you please examine what's wrong? Look into this method https://github.com/uiii/ProcessWire-FieldtypePDF/blob/d11ff962d520782fa25215f5ce606886773a5a44/FieldtypePDF.module#L232. Thanks
  13. @ICF Church Please go to the page /admin/module/edit?name=FieldtypePDF a post here the exact version of FieldtypePDF you have, thanks
  14. @ICF Church Hi, what version of ProcessWire and FieldtypePDF are you using?
  15. I had some problems with the database. E.g. the one @esper mentioned. So I deleted the table manually and uninstall the module, because it breaks the frontend when you accessing non-existing page. The error was something with myslqi and the message was Couldn't fetch ProcessWire\Database I'm using PW 3.0.70, i'm not sure if it was working on PW 2.6
×
×
  • Create New...