Comments (16)
Or just write that the assets needs to be compiled. It’s not a big thing to add it in the ci/cd-process.
from site-kit-wp.
It’s not a release without a dist, no.
And adding a repo endpoint to every package feels just so wrong when we all have packagist as default.
from site-kit-wp.
+1 for this, I was just about to submit it myself https://packagist.org/packages/submit?query=google%2Fsite-kit-wp and then found this ticket.
Why not just submit it there now, before it's fully released to stable, so that we can start using it without adding the github repo to our composer?
from site-kit-wp.
@archon810 As mentioned earlier in this thread, we cannot "just submit it there now", because the package would lack all the necessary built JavaScript and CSS assets.
Plus, the plugin would need to be tweaked to not include its own autoloader at all times:
site-kit-wp/includes/loader.php
Lines 17 to 18 in 13ca8a7
That's because with a Composer setup there is no vendor
folder within the plugin's folder itself.
Essentially, it would mean that we basically have to maintain two versions of the plugin:
- One suitable for distribution via Packagist
- One fully packaged for release on WordPress.org
from site-kit-wp.
That is just not true.
from site-kit-wp.
Compile and check in the assets in the dist folder. Composer is taking care och the autoloading.
Take a look at Roots Bedrock, WordPlate or any other standard Composer based WP solutions.
from site-kit-wp.
Since the plugin has been released on wordpress.org a while ago, the recommended way to include it via Composer is via wpackagist.org where it is available as expected since it is sourced by wordpress.org.
Having a separate published version on packagist.org seems unnecessary, more so because it would require packaging built assets in that version (since just publishing the GH version would not work).
from site-kit-wp.
You might want to read discussions at ampproject/amp-wp#5745 and ampproject/amp-wp#2649 for some context on why publishing a project like this to Packagist is not as straightforward as you might think
from site-kit-wp.
Just submitting the package is probably not enough, as it would need a dist version with built JS but without the bundled Composer packages.
from site-kit-wp.
Thanks for the issue!
We will explore that as an option. Once the stable release of the plugin is there, it will be available via wpackagist.org. For now, you can install it via Composer by providing something like this in your composer.json
:
"repositories": [
{
"type": "package",
"package": {
"name": "google/google-site-kit",
"version": "1.0.0-beta.1",
"type": "wordpress-plugin",
"dist": {
"type": "zip",
"url": "https://sitekit.withgoogle.com/service/download/google-site-kit.zip",
"reference": "1.0.0-beta.1"
}
}
}
]
from site-kit-wp.
@ekandreas Happy to be convinced otherwise :-) Can you perhaps elaborate on why that wouldn't be true? How do you intend to use this plugin using Composer?
To give some more context, we are currently in the same situation with the AMP plugin (ampproject/amp-wp#2649) and, according to a recent blog post, Yoast as well (https://developer.yoast.com/safely-using-php-dependencies-in-the-wordpress-ecosystem/)
from site-kit-wp.
Having worked at a marketing agency I feel like I should leave some feedback on this.
Fetching a plugin "natively" through composer implies dependencies are going to be consolidated at the vendor
directory, which in turn reduces disk usage by duplication. At a glance it may not seem like much but it's honest work it scales pretty quickly as more plugins are added.
One could say the most duplicated asset between plugins is actually frontend frameworks such as bootstrap, and it's not wrong, but every byte counts when you're running wordpress severless.
Then one could also say this kind of setup is not that common, to which I reply: Well of course not! The wordpress community as a whole hasn't fully embraced composer as the defacto dependency management solution to this day. Of course there are bigger offenders on that regard such as Elementor Pro and countless proprietary plugin update systems not acknowledging the existence of composer but that's kind of offtopic.
The point is: We're stuck in a (bad) feedback loop. And no effort is too small to help us break away from that chain.
I just think it would be cool to keep this kind of issue open along with some instructions on what needs to be done to get it going, just in case somebody wants to contribute.
from site-kit-wp.
@yangm97 As I mentioned before, you can currently install the plugin with composer, using wpackagist
(I'm actually using that on my personal site as well, which I manage with composer). Could you clarify what problem you see with that approach? What would be the benefit of having the plugin published separately on packagist
?
from site-kit-wp.
@yangm97 As I mentioned before, you can currently install the plugin with composer, using
wpackagist
(I'm actually using that on my personal site as well, which I manage with composer). Could you clarify what problem you see with that approach? What would be the benefit of having the plugin published separately onpackagist
?
The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.
from site-kit-wp.
The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.
That makes sense, in principle. However, by default Site Kit has all its production dependencies prefixed, so for those publishing on packagist wouldn't actually solve the problem. So if that's a crucial part of it, we'd need to cater for that, making this less trivial than just simply publishing it.
from site-kit-wp.
The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.
That makes sense, in principle. However, by default Site Kit has all its production dependencies prefixed, so for those publishing on packagist wouldn't actually solve the problem. So if that's a crucial part of it, we'd need to cater for that, making this less trivial than just simply publishing it.
Just imagine not doing the prefixing all the dependencies just for Packagist... basically ending up maintaining two versions of the plugin. Doesn't sound very appealing to me.
from site-kit-wp.
Related Issues (20)
- Update user input survey language HOT 1
- Group tiles in metrics selection panel
- Update Visit length metric tile display HOT 2
- Move tile percentage badges to bottom of tile HOT 3
- Fix typo in Set up conversions CTA HOT 2
- Update collapse arrows on user input summary HOT 2
- Update tooltip icon on mobile for tiles with longer titles
- Review and update Disconnect Analytics modal
- Error state flicker when navigating to Dashboard after changing connected property HOT 3
- First page reload after connecting Analytics causes page to scroll to #traffic instead of #key-metrics
- Link buttons (like "Edit") should have an updated design for active/focus state HOT 3
- Improve the handling of JS language packs with each plugin update
- Console Error when Custom Dimensions Metrics Selected While Analytics is Disconnected HOT 1
- Don't show the "Enable enhanced measurement" switch until an account has been selected in the setup flow. HOT 2
- Custom Dimensions tiles re-render on click
- Remove "Google" prefix from the "Connect GA CTA" banner button HOT 2
- Excessive requests to `container-lookup` on dashboard HOT 2
- Remove "CTR" from Most engaging pages tile HOT 2
- Error for report requests with custom dimensions HOT 5
- Ensure consistent styling of secondary CTAs across the plugin. HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from site-kit-wp.