After checking out the source from: https://github.com/RallyApps/app-catalog
I attempted to build the Portfolio Item cumulative flow diagram src/apps/charts/rpm/cfd locally using
rally-app-builder build which shows no errors
Launching App-debug.html allows me to input the relevant settings, but once I click 'save', nothing renders and there are no errors logged to the JS console either, making debugging challenging.
I attempted to copy the build output into a custom html app inside rally, which displayed the same behaviour.
Is this a bug with the example app? Or have I missed some crucial configuration step?
EDIT:
Extra info - I tried running via the rally-app-builder to no avail (think it's related to this issue: https://github.com/RallyApps/rally-app-builder/issues/45). I attempted to flatten the structure and the result of that was a cross-origin request error.
Running from file resulted in a 403 for the SDK
Sorry about that- that Rally App Builder issue is definitely the problem you're running into. Just as a test I downloaded the built html output for that app from the app catalog release: https://github.com/RallyApps/app-catalog/releases/download/2.1/2.1.zip
It worked when installed on a custom html app on my dashboard once I edited the app settings and configured a portfolio item.
If you're looking to tweak this app from source you'll probably have to copy all those files referenced in config.json that live in parent directories into the main app directory and fix the paths in config.json. Then you should be able to build and run the app normally using Rally App Builder.
It seems this app was really not designed to be run externally, so I added a little code to ease the issues I ran into:
In PortfolioChartAppBase.js, _loadSavedPortfolioItem function:
scope: this,
fetch: ['Name', 'ObjectID'] //this is new
And I added some default settings as a top level config object in CumulativeFlowChartApp.js (since the code to force into settings mode doesn't seem to work correctly when running externally):
config: {
defaultSettings: {
portfolioItemPicker: '/portfolioitem/feature/52725935318', //insert a valid oid here
startDate: 'actualstartdate',
endDate: 'actualenddate',
chartAggregationType: 'storycount'
}
},
Related
I've been trying to get live preview in Sanity to work for several days now, without luck.
It works like a charm when I follow this tutorial:
how-to-quickly-set-up-a-gatsby-js-jamstack-website-with-a-headless-cms.
But when I create a starter blog like this one: sanity-template-gatsby-blog, it does not work at all.
I've followed three tutorials, but it always fails, even if I do exactly the same.
This is my gatsby-config:
module.exports = {
plugins: [
"gatsby-plugin-postcss",
"gatsby-plugin-react-helmet",
{
resolve: "gatsby-source-sanity",
options: {
projectId:"nt51j1jx",
dataset:"production",
token: "ABC123", //this is a dummy for this post
watchMode: true,
overlayDrafts: true
},
},
],
};
When I create a new post and click "web preview", I get a 404
It does not help to click publish, and I can't see any changes on the local host.
Changes to existing posts are also not visible.
I have to restart the server every time I want to see the changes. That's not the case with the first template I mentioned, but that one crashes when I try to install Sanitys code-input plugin, which I need.
Thanks in advance!
I finally solved it by following this post: https://www.frontendstumbles.com/gatsby-and-sanity-cms-tutorial/
A nice step by step guide that creates a Gatsby and Sanity starter that works with watch mode and drafts mode.
The preview environment must be rebuilt when you create a new page.
That's a new static html file to be built. This is different from live preview updates, which amend the page data client-side.
UPDATE: Sanity + Gatsby Cloud Live Preview is a known bug at the moment. I guess we join the Slack channel to hear when they fix it?
Im struggling to add adobe analytics external scripts to my Vue js project. The client uses Adobe analytics and im battling to add it to the project without the project complaining.
The external adobe script looks like the following:
//assets.adobedtm.com/file.min.js with async
Then it is required that you end it by adding the following just before the closing body tag:
<script type="text/javascript">_satellite.pageBottom();</script>
When the project starts it complains in console that $ is not defined because it is defined in webpack when i start the project and im guessing its not finding the alias.
This is the error:
VM29714:3 Uncaught ReferenceError: $ is not defined
Then further down it complains that it doesnt know what _satellite is:
login:54 Uncaught ReferenceError: _satellite is not defined
I just need the scripts and satellite close to be added to the project, the rest will work once these are added.
Ive tried added the scripts by injecting them into the head tag on runtime but that also doesnt work.
If you are implementing Adobe DTM, you cannot inject the header script dynamically. It must be placed directly on the page without async or deferred attributes.
If you are implementing Adobe Launch, you can inject the header script dynamically and asynchronously. And if you do this, you do not include the footer (_satellite.pageBottom()) code.
Your script example isn't explicit, but the .min portion implies you are using Adobe Launch.
VM29714:3 Uncaught ReferenceError: $ is not defined
This is not directly related to either Adobe DTM or Launch. You may possibly have some other script or code block deployed inside the DTM or Launch interface that references $, but that's a separate issue to work out. Yes, it may be coming from a DTM or Launch script according to the js console, but keep in mind that DTM/Launch is a tag manager. It hosts and deploys other tags/scripts. So you need to do some digging to see which tag/script from which Rule references it. Start by looking at the stack trace to find out where it's coming from.
I built an Electron app and I am now looking at how to distribute it.
I went with electron-builder to handle packaging etc.
For a bit of context, as a web developer, I am used to continuously deploy web apps on a web server but I have a hard time figuring out how to distribute a packaged one in Electron.
In electron-builder docs there is a brief mention about testing auto-update:
"Note that in order to develop/test UI/UX of updating without packaging the application you need to have a file named dev-app-update.yml in the root of your project, which matches your publish setting from electron-builder config (but in YAML format)"
But, it's rather vague...
So I actually have two questions:
1. How do I actually test the auto-update flow?
Do I need to actually publish a new version to trigger an update locally? Seems pretty unclear, it would be like developing against the production server.
2. Is it possible to have a fallback for unsigned code?
I don't have yet any certificate for code signing. So the OS/app will block the auto-update. But, I'd still want to tell the user that an update is available so they can go and download the app manually. Can I do that? (going back to point 1, I'd like to be able to test this flow)
I've just finished dealing with this. I also wanted to test against a non-production server and avoid having to package my app each time I iterated. To test downloads I had to sign my app, which slowed things down. But it sounds like you just need to check for updates. Which I think you can do as follows...
I created a dummy github repo, then created a a file dev-app-update.yml containing:
owner: <user or organization name>
repo: dev-auto-update-testing
provider: github
The path where this file is expected to be defaults to a place you can't access. Thankfully, you can override it like so:
if (isDev) {
// Useful for some dev/debugging tasks, but download can
// not be validated becuase dev app is not signed
autoUpdater.updateConfigPath = path.join(__dirname, 'dev-app-update.yml');
}
...that should be enough for your case -- since you don't need downloads.
If not, here are some other tips:
you can change the repo setting in your electron-builder config to point at your dummy repo then package your app. This will give you a packed, production build that points at your dummy repo -- this is how I did my download testing (though I have a cert, and signed my app)
you should be calling autoUpdate's checkForUpdates(), but if checkForUpdatesAndNotify() gives you a useful OS Notification then you should be able to set autoUpdater.autoDownload to false and end up with what you need.
Lastly, it sounds you could skip autoUpdater, since you won't be using the download feature anyway. Instead you could use github's releases api, assuming you use github to host your release. If not then your host should have something similar. Use that to check for updates then tell the user from within your App (could present them with a clickable URL too). If you want OS Notifications electron has a module for that.
We're using electron-updater with GitHub as a provider for auto-updates. Unfortunately, it breaks a lot and the electron-builder team doesn't support these issues well (1, 2, 3) (from my own experience, but you can find more examples on GitHub).
One way to test updates in dev mode:
Create a build of your app with an arbitrarily high version number
Create a public repo and publish the above build
Create a dev-app-update.yml next to your main entry point and configure it for the repo above (see)
In your main entry point:
import { autoUpdater } from "electron-updater";
...
if (process.env.NODE_ENV === "development") {
// Customize the test by toggling these lines
// autoUpdater.autoDownload = false
// autoUpdater.autoInstallOnAppQuit = false;
autoUpdater.checkForUpdates();
}
Then when running yarn dev you should see something like:
Checking for update
...
Found version 100.0.0 (url: <>.exe)
Downloading update from <>.exe
updaterCacheDirName is not specified in app-update.yml Was app build using at least electron-builder 20.34.0?
updater cache dir: C:\Users\<>\AppData\Local\Electron
New version 100.0.0 has been downloaded to C:\Users\<>\AppData\Local\Electron\pending\<>.exe
And it should install when you close the dev app.
This should give you some certainty but we still ran into issues in production. If you want to be sure, play through the full update flow with a test repo but packaged production apps just as you would do with the live one.
Since around 10:30am EST today, I have been unable to apply stencil custom themes successfully. Any theme bundled before 10:30am EST today works fine when applied to a storefront. The themes work fine locally, and there are no errors when bundling, but once the theme is applied, the page loads HTML without images or any styling applied. The error in the console reads "TypeError: window.stencilBootstrap is not a function".
I have verified the issue on multiple accounts, and even occurs when trying to bundle and apply a fresh Cornerstone clone.
There are no reported issues on status.bigcommerce.com
Is anyone else having similar issues today?
Do I need to update my CLI?
Thanks
At the time of giving command stencil bundle, it will clear 'assets/dist' files. So that throws error theme-bundle.main.js file missing and window-stencilBootstrap is not a function.To avoid Clearing 'assets/dist' follow below steps.
Comment this below line in webpack.conf.js which is in root folder
/new CleanWebpackPlugin(['assets/dist'], {
verbose: false,
watch: false,
}),/
After this, run stencil bundle 'asset/dist' folder will not clear by doing so. Check u have 'assets/dist' folder then upload. After uploading your theme, front end will works fine.
This is a bug at stencil-cli.
There is an open issue for it: https://github.com/bigcommerce/stencil-cli/issues/379
I have just submitted a pull request with a possible fix: https://github.com/bigcommerce/stencil-cli/pull/409
In the issue, I suggest a workaround which can be done in the theme, without having to modify stencil-cli.
At stencil.conf.js, remove these two lines from the top of the file:
var webpack = require('webpack');
var webpackConfig = require('./webpack.conf.js');
Copy them as the initial lines of development and production functions, where these variables are actually used.
This change usually fixes the issue.
I recently installed the latest Worklight fix pack update, and am now running v6.2.0.01.20141027-1531
Since that, I've noticed a blocking bug about my common environment deployment on the WL server.
Now when I deploy my app ("Run as > Build all environments" and then "Run on Worklight development server"), running my app in the "Preview as common resources" or in the iPad / Android mobile web environments give me the following Javascript error :
WL is not defined
When I inspect the source code, I realize that the "Worklight generated" Javascript source code is missing in the head tag. I'm supposed to see something like this :
<script>
// Define WL namespace.
var WL = WL ? WL : {};
/**
* WLClient configuration variables.
* Values are injected by the deployer that packs the gadget.
*/
WL.StaticAppProps = {
"APP_DISPLAY_NAME": "appname",
"APP_ID": "project",
"APP_SERVICES_URL": "\/project\/apps\/services\/",
"APP_VERSION": "1.0",
"ENVIRONMENT": "preview",
"LOGIN_DISPLAY_TYPE": "popup",
"LOGIN_POPUP_HEIGHT": 610,
"LOGIN_POPUP_WIDTH": 920,
"PREVIEW_ENVIRONMENT": "common",
"WORKLIGHT_PLATFORM_VERSION": "6.2.0.01.20141027-1531",
"WORKLIGHT_ROOT_URL": "\/project\/apps\/services\/api\/app\/common\/"
};
</script>
...but there's nothing like this in my page's source code (that's why the WL is not found).
Moreover, it does not include the worklight.js and wljq.js files that are supposed to be dynamically added during the build phase (as far as I know). My index.html content is "vanilla", and it explains why nothing works.
So I decided to check in the bin archives that are generated during the build phase. It happens that the app-common.wlapp archive contains the correctly generated source code, with all the Worklight generated stuff inside. It looks like something wrong is happening during the deployment step. I tried to import it manually in the WL Console, but it's unfortunately not working either (same result).
I did not manage to reproduce the problem creating a new project, it looks like it only happens after an update of Worklight to the latest fix pack version. Thus, it's complicated to provide a sample project.
NB : everything works fine once running on an actual device. Only the common environment is broken in my case. But a colleague of mine also noticed this issue for the other environments so... I'll let you know if I manage to reproduce it for the other environments.
Thank you for you help, please ask if you need more inputs from me.
You are not required to do "build all..." and then "run on...". That's just repeating the same step, as "Run on Worklight Development Server" means "build the project artifacts (.wlapp file, .war file) and then deploy them".
A vanilla index.html contains references to initoptions.js, main.js, main.css and messeages.js. You are kinda confusing in your wording as to what is expected and where is it expected.
Anyway, try the following:
Close Eclipse
Go to your tmp folder and delete the wlBuildResources folder
Open Eclipse and try the following two paths:
Right-click the app folder > Run As > Run on Worklight Developer Server > Open Worklight Console > preview as common web resources
Right-click the app folder > Run As > Preview
Tell me which of the two fails, if at all.