Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. https://github.com/processwire/processwire-issues/issues/905
  3. Yesterday
  4. Yeah, it's pretty bare-bones at the moment. A form to allow folks to manually submit finds/report classification errors would be neat too.
  5. This is great, thanks! It would be cool if there was a filter option to show only assets that are not in the modules directory.
  6. Not sure if you have in mind a site profile for generally sharing with the community, or something that is made available only to some specific users/clients. If it's the former I would think option 1 would be necessary if you want the profile to be usable by a wide audience. I expect there are many here who are not running Git or Composer. And as you say you would update the profile from time to time (not really different in that regard from a module you have authored). If it's the latter then another option could be @bernhard's Kickstart tool: You would provide users with Kickstart settings that point to a remote profile zip that does not include any third-party modules within it, and then add the third-party modules in the "recipe". That way a user who is installing the profile always gets the latest module versions. I suppose you could use the Kickstart approach for a generally shared site profile too but it comes back to the audience thing again. If PW beginners should also be able to use the profile then it's probably best if the profile can be installed as per the standard procedure without them needing to learn any additional tools.
  7. Ok, I think the directory is about there now. Has about 1400 assets - many of which are not available via the modules directory. Enjoy.
  8. hey @schwarzdesign, so pleased to see you finally found your way to processwire! awesome work i enjoy frequently on my mobile.
  9. I had some use case, were I have to show some data from my $page->meta() to specific users in the admin panel while they edit the page. I used FieldtypeRuntimeMarkup and created a field which makes only the output of this meta values. It works well.
  10. I forgot to write some update here. We made some minor and one major release since 1.0.0 with this changes: fix some log warnings from some Repeater fields Module can now be installed via composer Add support for $config->elasticsearchFeederConnectionOverride Better support of own hosted ElasticSearch Servers Use of PW 3.0.133's new $page->meta() feature instead of creating a fields for indexed pages CI Tests via circleci.com and peridot-php Current Version is 1.2.0 and since we use $page-meta() the module requires now PW 3.0.133 And a live production demo will follow the next 1-2 weeks.
  11. This is not an easy question, and so also isn't the answer. Personally I would prefer Git submodules as it would be less effort for users who doesn't have either Git nor Composer understanding. Also Git is very tiny action to install and running, composer seems to take more effort. So, for users who have both capabilities, I also would go with option 3, the composer dependencies. My conclusion is, it depends on your main target group.
  12. Sorry @teppo, i am new here. Will learn the rules... Thank you..
  13. So, I've been working on a site profile and came across something I'd like to get some input on. Like probably many other site profiles out there, this one also depends on (and thus includes) third party modules. What I'm wondering is: what would be the best way to include them with the site profile? I can think of three possible / feasible approaches: Bundle the modules into the site profile as-is, i.e. include the full module directories. Benefits: just install the site profile and the module is instantly available. No other dependencies and doesn't require any knowledge beyond "how to install a site profile". Drawbacks: updating the module requires updating the files manually, or updating via Admin (which may not be permitted, and may not be a suitable option in case the whole site is stored in a version control system). Unless the site profile is manually updated from time to time, it may initially contain very old module versions when installed. Add module repositories as Git submodules. Benefits: modules are easy to install and update with Git, just run "git submodule init" followed by "git submodule update". Drawbacks: Git and some basic understanding of its command-line use is required, and simply installing the site profile itself isn't enough to get it up and running. Add modules as Composer dependencies. Benefits: same as with the submodule approach, but perhaps a bit more flexible – possible to define minimum versions, minimum stability, etc. Also: this would be familiar approach for many PHP devs, while something like Git submodules seem to be less commonly used. Drawbacks: obviously requires Composer and command-line access, plus a basic understanding of what Composer is and how it works. Module directories won't contain .git folder, so can't be updated with Git commands (not sure if this is a real drawback, though). What would you prefer, or which approach do you currently use? Any other ideas? I'm kind of leaning towards the Composer method, mainly because I'll likely have other Composer dependencies as well, so it would actually require fewer steps than including modules as Git submodules. Still the submodule approach does have certain benefits, like easier updates (sort of, at least) -- Note: since there's no separate forum section for site profiles, and technically this may apply to literal modules as well, I'm posting this the Module/Plugin Development area. If any of the moderators disagrees, I'm happy to move the thread to another area instead
  14. Thanks, I just used the z-index: 11 you suggested in v2.017. There's a very high z-index on the datepicker calendar div added by AOS that was needed back then. This is still above the masthead on scroll but I think it's better not to change that. There's also a bunch of new CKEditor plugins added in this version: Color Button Color Dialog Table Resize Table Tools Table Tools Toolbar
  15. Omg what? I’ve been paying for it since then too (upgrades and support) haha! I’ll upgrade and check!
  16. You must have an old version of FieldtypeTable - it has included Page column types since 2015: https://processwire.com/blog/posts/major-updates-to-profields-table-field/#new-support-for-single-and-multi-page-reference-fields
  17. Wanze


    Done, thanks for the hint! I was thinking that ProcessWire would update this information regularly?
  18. Thanks Teppo I thought there must be a way to store data without creating table.
  19. flydev


    @Wanze please force the module directory update
  20. UPDATE 2019-06-15 The taxes repeater field in module config editor was updated: changed to a grid view for more flexibility added field validation prepared the taxes-repeater field code to become a standalone flexible Inputfield module for general use (Array/JSON repeater input field which stores its values in a single text field) The taxes handling is completed! SnipWire now acts as a full flexible taxes-provider for Snipcart (we use Webhooks for this). No configuration needed in Snipcart dashboard. SnipCart orders are now fully working (except shipping handling). The sample shop templates got an update: customer login/logout customer dashboard link/button to view orders history and subscriptions editing of customer profile Other updates and fixes: The SnipWire Dashboard was updated (Charts, Orders, Customers, ...) --> see screenshot below. The Dashboard fetches its data from Snipcart via CURL multi - the response time for a fresh load is now under 2 seconds The Webhooks handler now supports all Snipcart events via hookable methods. Snipwire now supports all major Admin themes (Uikit, Reno and Default) All module classes/files are more structured (e.g. separate helper and service classes) Under the hood many bugs are fixed and code is updated to prevent unexpected errors. Added a crispy SVG logo for all SnipCart back-end pages Screen-recording of updated taxes-repeater: Screenshot of SnipWire Dashboard:
  21. Wanze


    Version 0.8.0 has been released: Adds facebook share preview for content editors when editing Opengraph meta data Adds support to extend the rendered meta title with additional information such as the domain or site name (#11) Renders structured data (JSON-LD) for breadcrumbs via new group "structuredData" (#10) Adds new meta group "structuredData" which will handle more types of structured data in the future Happy weekend everyone! Cheers
  22. Googlebot is clever these days. JS-content is no problem for indexing anymore (React, Angular, Vue etc.). Meta tags and page titles are adjusted for every page-view (something a lot of developers simply forget when building SPAs). Of course, you could always improve SEO, e.g. creating a sitemap.xml... https://www.smashingmagazine.com/2019/05/vue-js-seo-reactive-websites-search-engines-bots/ ^ a good read about the subject
  23. @Robin S Many thanks for this. I will try it soon!
  24. Congrats, looks amazing and performs super fast. Just a short question. Did you have any concerns about SEO impact since everything is done through VUE and there is no real source coude there?
  25. Ah but it looks like I cannot add a PageField as a column type?
  1. Load more activity
  • Create New...