Jump to content

thetuningspoon

Members
  • Posts

    676
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by thetuningspoon

  1. We had an incident where we tried to upgrade one of our sites to 3.0.200 and needed to roll back (we had only intended to upgrade the staging site but some configuration confusion led to the live database also being affected!) The site was previously on 3.0.165. When we tried to roll back the files, we were unable to because it resulted in numerous errors about missing module classes being triggered inside of other modules. Here are some examples: Uncaught Error: Class 'ProcessWire\InputfieldText' not found in /var/www/live/wire/modules/Inputfield/InputfieldEmail.module:16 Uncaught Error: Class 'ProcessWire\InputfieldCheckbox' not found in /var/www/live/site/modules/InputfieldSlideToggle/InputfieldSlideToggle.module:3 Uncaught TypeError: Argument 1 passed to ProcessWire\Pagefile::__construct() must be an instance of ProcessWire\Pagefiles, null given, called in /var/www/live/site/templates/model/TransmissionProcessor.php on line 598 and defined in /var/www/live/wire/core/Pagefile.php:131 Exception: Method Languages::hasPageNames does not exist or is not callable in this context (in wire/core/Wire.php line 564) Fatal Error: Uncaught Error: Class 'Fieldtype' not found in site/modules/FieldtypeDecimal/FieldtypeDecimal.module:13 This persisted even after clearing compiled files and triggering a module refresh. Can anyone think of what database changes might have been triggered by the upgrade from 3.0.165 to 3.0.200 that would result in these sorts of errors? I have occasionally "downgraded" ProcessWire before without having this kind of issue, or at least it wouldn't persist after refreshing modules and clearing compiled files.
  2. Sorry for the delay. At this point we're really looking for someone who is in the South Windsor, CT area or who could relocate for this full-time position. We currently work in the office 2 days a week and work from home the other three. But my boss (the owner of the company) says he is also interested in making connections as there is the possibility of contract work on an individual project basis or perhaps full time remote work at a later date.
  3. Sorry about that. I'll try to update with some more information asap.
  4. The company I work for in central Connecticut, Solution Innovators, is looking to hire a programmer with ProcessWire experience to join our small but growing team. We've been working with PW since 2012 and have numerous marketing sites and web applications built on it. Strong PHP skills are a must, with experience building object oriented systems and organizing and documenting code in a clean, maintainable and reusable fashion (like the ProcessWire core). Skills in Vue.js, javascript, jQuery, html, and css are a plus. DM me for more information!
  5. Great. I forgot (or maybe never knew?) that boot.php existed!
  6. We've built an intranet for one of clients in ProcessWire before and it worked out nicely. Be sure to test all your roles and permissions carefully by creating test users for each. You might need to do some hooks or use some modules to get the level of control you need for your users.
  7. Have you tried adding the namespace to the autoloader inside site/init.php instead of site/ready.php? wire('classLoader')->addNamespace('ProcessWire', wire('config')->paths->templates . "traits/"); If you have usePageClasses set to true in the config.php and are using the /site/classes/ folder then I would think this wouldn't even be necessary since that should already be included in the places for the autoloader to look. I haven't come across the need for traits yet, although I keep forgetting that they exist in php now. When I think of composition I usually think of moving certain functionality out into a separate class that would then be instantiated somewhere inside the other class. You can create classes that don't extend Page (perhaps that that extend Wire or WireData if you want easy API access) and then use those in your Page derived class. Your example is probably intentionally oversimplified, but sometimes I find that sometimes a bit of duplicated functionality is really just incidental and doesn't actually justify creating a new layer of inheritance or a separate class at all, especially as you might later discover that the two functions actually serve slightly different purposes and at that point are tied together and difficult to pull apart. You could also use a PW hook to add this function to both classes, although it wouldn't be as elegant.
  8. If I get some time I would love to work on building a module that would deliver a Craft CMS style solution for this, since I think that would work best for our projects. Just not sure whether I’ll get that chance or not.
  9. Thanks @bernhard, that's helpful. I'm still not sure how the typical workflow would look, though. Would you create a new file for each set of changes that you make to your site? Or do you just keep updating that one array that defines all of the templates and fields for the whole site (like a declarative configuration file)?
  10. I looked into it a while back but wasn't sure how to use it. I think I need a little tutorial that walks though a particular use case.
  11. I actually find that ProcessWire plays pretty well with Git, certainly in comparison to WordPress. The main thing is to avoid installing modules via the admin UI (just download the module and put it in your repo). And of course exclude /assets/ from the repo (PW conveniently keeps all of this together). It would be nice to be able to exclude the wire folder and have Composer handle that instead, but I don't find it that big of a deal to keep the wire folder in Git. In the very rare case that a direct core mod is necessary for a project I'm working on, it's good to be able to make that change and commit it to the repo. The ability to maintain a master configuration file containing all of the meta data for the templates and fields in a project and to be able to put this into version control would be a real game changer, though. This is a real pain point we're running into on a lot of our projects, especially now that we have a couple systems that have multiple deployments and multiple developers working on them. Since we already have JSON export for templates and most field types (the options field export/import is still not fully functional), it doesn't seem like this is too far off. Maybe PW could cache a copy of the JSON configuration file and then if it gets updated externally, show a message in the admin that there are pending field/template changes to be applied, allowing the user to apply these changes with a single click. If it makes it easier/cleaner, there could be 2 config files, one for fields and one for templates (and maybe another for modules?) I'm curious how other systems handle this under the hood. Edit: Here's how Craft CMS does it: https://craftcms.com/docs/3.x/project-config.html#propagating-changes This sounds a lot like what I'm thinking. The command line option for applying changes is also a great idea since some changes could take a while to apply on large projects.
  12. You don't have to. For example, you could put the username and passwords into the config-env.php instead, and still have the rest of the advantages of sharing the config file. But if you manage your own git server securely then it shouldn't be a problem. I'm interested in hearing your thoughts if you think otherwise, though. In your example, are you not including the config file in git? I'm confused as to why you would be including both the dev and prod settings in a single config file if you aren't.
  13. What you've done with the first example looks super powerful. Nice work. The second approach is what we use. It's always a battle between giving the client more control vs. making it easier for them to manage (and making sure they don't mess up the site's aesthetic!). So we tend to give them more clearly defined components and then add options to them as they need them, or build out new components if they want something totally new. With the example of the text w/ image block, you could create a single block but add a radio button for which side the image goes on.
  14. Just wanted to share the new approach we've started using for our configs. Instead of multiple config files, we are using a single shared /site/config.php plus a custom /site/config-env.php file that is unique for every environment the site is deployed (or developed) in. The config-env.php file simply contains one $env variable with a string that defines which environment we're working in (e.g. "production" "staging" "dev") and we include this file within the usual /site/config.php file. The config-env.php file is excluded from git (gitignore) and from our deployment scripts, so it won't be overwritten or touched after it's set up. Using a file to determine the environment rather than the domain or server variables means that it will work regardless of where or how it's invoked (cli vs browser). Here's the basic format: Example /site/config-env.php <?php $env = 'production'; // A string identifying the current environment Example /site/config.php <?php if(!defined("PROCESSWIRE")) die(); setlocale(LC_ALL,'en_US.UTF-8'); ini_set('session.gc_probability', 1); ini_set("log_errors_max_len",0); /*** SITE CONFIG *************************************************************************/ /** * Set up all your defaults and settings that are shared by all environements below */ $config->debug = false; $config->adminEmail = 'example@example.com'; $config->advanced = true; $config->templateCompile = false; $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; $config->chmodDir = '0775'; $config->chmodFile = '0664'; $config->timezone = 'America/New_York'; $config->defaultAdminTheme = 'AdminThemeUikit'; $config->installed = 1527694349; /** * Environment-specific configs */ if(!file_exists(__DIR__ . '/config-env.php')) { echo 'No /site/config-env.php file could be located. Please create a /site/config-env.php file with a single $env variable containing a string identifying the current environment. This file should NOT be committed to Git (add it to the /.gitignore file) and must be excluded from deployment.'; exit; } require(__DIR__ . '/config-env.php'); if(!isset($env)) { echo 'No $env variable found in /site/config-env.php'; exit; } switch($env) { /** * Production */ case 'production': $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Staging */ case 'staging': $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Developer One's Dev environment */ case 'dev1': $config->debug = true; $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Developer Two's Dev environment */ case 'dev2': $config->debug = true; $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; default: echo "No configuration found in /site/config.php for the environment string \"$env\""; exit; } If you wanted, you could make the $env variable $config->env instead, which would allow you to access it from anywhere else on the site using wire('config')->env
  15. Watch out with this. If you're running a cli script or cron job, the SERVER_NAME will not be set and you may end up running it on your live database instead of your development!
  16. This has been an intermittent issue for me with PW as long as I can remember.
  17. @Noel Boss For some reason this doesn't work with your change from using add() to using $page->set() (PW 3.0.178). I got it to work and figured out a way to clear the orphans message: $field->setOrphans(new PageArray()); $page->{$field->name}->add($page->children('include=all, check_access=0')); I also added include=all and check_access=0 to make sure all children get added. Here's the resulting full hook method: /** * Fill pagetable fields with children before editing…. * * @param HookEvent $event */ public function addChildrenToPageTableFieldsHook(HookEvent $event) { $field = $event->object; // on ajax, the first hook has no fieldname if (!$field->name) { return; } // get the edited backend page $editID = $this->wire('input')->get->int('id'); if (!$editID && $this->wire('process') instanceof WirePageEditor) { $editID = $this->wire('process')->getPage()->id; } $page = wire('pages')->get($editID); // disable output formating – without this, the ajax request will not populate the field $page->of(false); // you could also insert a check to only do this with sepcific field names… $field->setOrphans(new PageArray()); // Clear out the "orphans" notice $page->{$field->name}->add($page->children('include=all, check_access=0')); }
  18. We've been playing around with findRaw but it looks like it doesn't support getting fields from the parent page like it does for page fields. Any chance we can get that feature added? 🤞 😇
  19. This sounds fantastic. A couple of our clients have been wishing for something like this and have tried using the clone/copy feature to try to achieve it, but then have issues such as the CkEditor fields pointing to the wrong page's files. Would this feature resolve that issue?
  20. Seems like it should be mentioned somewhere that the pageFileSecure settings only works with files added after it is enabled.
  21. Glad you're finding it useful! You are correct--I don't believe I ever added support for the read-only state of the various inputfields. Feel free to submit a pull request if you do work on this.
  22. Posted by: <?php if($page->insight_author): ?> <a href='<?= $page->insight_author->url ?>'><?= $page->insight_author->title ?></a> <?php endif ?> , <?php foreach ($page->insight_author->roles as $role): ?> <?= $role->staff_role ?> <?php endforeach ?> I would suggest something like the above, though there are certainly other templating styles. Like @monollonom said, I'm not exactly sure what role represents or how that is structured.
  23. @ryan I'm trying out the new join feature within a regular page selector. I believe you mentioned that it is possible to join subfields of page fields. I'm wondering if you can explain that in a bit more detail. Does this still all happen within a single SQL query? If I want to join the id and the title of a page in a page reference field, which of the following is the proper way to do this? $pages->find("template=foo, join=pageField|pageField.title"); $pages->find("template=foo, join=pageField.title"); // Can I join pageField.title without also joining the pageField? If so, would I still have access to the page id? $pages->find("template=foo, join=pageField.id|pageField.title") // Is joining pageField.id the same thing as joining pageField? I could answer these questions for myself if I knew of a good way of checking which data has already been loaded in the resulting page. What is the best way to double check what field data is already loaded on the page objects after performing a find (in order to make sure the join worked properly)? Edit: I just realized I wasn't thinking clearly when I wrote this. Being able to join subfields of page reference fields would require loading those pages as their own separate page objects, which would always include the page ID, name, modified, and created dates. I am still wondering whether doing either join=pageField or join=pageField.title would actually cause those pages to be preloaded as part of the find, or whether it would only lazy load them when first requested, per the normal PW behavior.
×
×
  • Create New...