Closed spidersbite closed 6 years ago
Hi @spidersbite ,
The latest version is always the master branch of the sp-dev-fx-webparts just like the link you provided. However, the .sppkg made available on github is just for quick demonstration purpose, I highly suggest you not to use this .sppkg on a production environment for many reasons. You should always clone the master branch on your dev environment, build it yourself (using your own cdn url) and upload the resulting sppkg to you different environments.
That being said, it is not a verison problem, the problem you are describing seems really weird to me because this is not how it behaves when trying the same .sppkg on my side. Normally when you select another site, you have to select another web as well, then once you loaded the other web it should display the lists of that newly selected web.
Are you sure you did select another site? Are you sure it's not just because you have the same lists titles on both sites? I have a hard time understanding how this could happen...
Can you provide screenshots of the steps you take? Otherwise we could share desktops on skype if you want.
Yes, I am certain I selected another site. The lists on Sites A and B are completely different, so I know I'm seeing Site A lists. I had previously used this on another site without issues like these - the lists for the site I selected displayed fine.
I didn't realize this was just a demo. Are you planning to publish a production ready version of this?
The project itself is more than a demo, it is production ready, but users should build it on their own and use their own .sppkg. The reason is because when building the project with gulp, you tell the .sppkg the url of the CDN in which the binaries are located. The .sppkg I provide is configured to go read it’s binaries on MY tenant, which means that the day I close my tenant, the sppkg refering my tenant won’t work anymore.
Thats why you should build the project while specifying YOUR tenant as a CDN url, that way you are the one hosting the binaries not me :)
In the latest version of SPFX, this is not a problem anymore because binairies can be hosted directly in the .sppkg, however in order for this webpart to stay compatible with SP2016 on-prem, I decided not to upgrade to the latest version and use the original CDN method instead
Now as for the problem, are you able to provide screenshots of the steps you take when configuring the webpart? You are saying it works fine for different site collection but you have the problem with those two site collection in particular?
Otherwise a skype meeting would also be possible
@spidersbite after testing the WebPart on pretty much all the site collections I have, I managed to replicate something similar on my side. When selecting one site collection in particular, the Web Url dropdown underneath the Site Url dropdown was not showing any webs. When closing the WebPart and re-opening it moments later, the Web Url property was configured to blank and then I could indeed see the list from the current web even if I had a different site collection selected.
The issue really was that there was no web returned by the search for that particular site collection, causing the WebPart to act weird without any web selected. I did a fix that works on my side, I would be curious to know if it fixes your problem as well.
I also added a "Search within folders" switch so the user can decide if he wants the query to be recursive accross folders or not.
I just submitted pull request #463 on the sp-dev-fx-webparts repository, it should be merged to the master branch soon enough.
If you don't wanna wait until the merge to try it out, you can go get the latest version (1.0.9) directly on the dev branch of my fork which I used to do the pull request. You can download the .sppkg directly from there and try to see if it helps.
Let me know the result 👍
@spplante thanks for this. I tried downloading the sppkg from your dev branch. I used it to replace what was in my app catalog but it still shows up as 1.0.8.
@spidersbite if you used the link I provided, it's my mistake, I gave you the wrong link which was pointing to the master branch of Microsoft's repository.
Here is the correct link for the dev branch of my fork.
You should see the comment Added the "Search within folders" switch which enables the WebPart to… next to the .sppkg which is the last check in I did.
Also, when adding the .sppkg to the app catalog, the modal window that will open for the "trust" should be pointing to a folder 1.0.9
Let me know!
@spplante I've successfully added 1.0.9. I can see that it's on my site where I am working. I added the react content query webpart and tried to configure it, but similar problems occur. I choose the site url of the other site from which I want to get a list. Web url dropdown says "Select the source web..." but doesn't allow me to select anything. When I publish/edit the page sometimes I can see the List Title dropdown appear, but the lists are only for the site I am on and not the one I need to retrieve from.
Hmm thus is exactly the problem I had before the fix. For some reason, the search does not return the subwebs for particular site collections, it really looks like something wrong with the search.
Do you have only one subsite within that site collection?
I'm not working with subsites. I have one site collection and I'm trying to take a list from a different site collection. I can choose the different site collection's site url, but the two fields below it are behaving as I described. Is it not possible to pull lists between site collections?
A site collection has webs. When you create a site collection, it comes right away with a root web. When selecting a site url, the WebPart should display the webs for the selected site collection. The first one will always be the "/" web, which is the root web. Then if you have other webs within the site collection, the web url dropdown will also display them.
So typically, if a site collection /sites/mysite only has a root web, the web url dropdown should display one web :
If a site collection /sites/mysite also has subwebs, the web url dropdown should display them as well:
So the answer is yes, it is possible to pull lists between site collections, didn't you tell me that you were able to do it with other site collections?
It should normally show at least the web "/" which is the root web of your site collection, but for some reason the search is not returning it, this is currently what the problem is. The WebPart will never show the correct lists if no web is selected, and right now the issue is exactly this, no webs are generated which means you can't select any. I will investigate and come up with another fix.
Meanwhile just to help me understand, can you try using another site collection to see if it works? Or it does that for any site collection you select?
@spidersbite can you clear your cookies and retry with the same version (1.0.9) just to make sure the WebPart does not run under the some old cached code from 1.0.8?
Also, can you provide me the relative url of the site collection you are selecting? I need this part :
/sites/mySiteCollection
Let me know if you get the same result after clearing cache
I tried clearing my cache in both IE and Chrome. Unfortunately, same results.
Hmm im heading towards an interesting path. Quick question, is the problematic site collection a Private Group by any chance?
No, both sites - the host for the web part and the site with the list I want - are public sites shared with Everyone. They are not groups.
This is weird because I just found out how to replicate the problem 100% of the times on my side, and it is only happening when selecting private groups. The reason why is because I have to include the &Properties=’EnableDynamicGroups:true parameter in the REST search request in order to the search results to include private groups.
Just to make sure, you realize I am talking about private "Microsoft Groups" which is a modern team site attached to an outlook group, and not a security group or anything of that matter? And by private I am not talking private in terms of access, I am talking Private in terms of group type (there is public and private groups). You could have a "Private" group (modern team site) with everyone with read access, it would still be a private group.
If you click on the gear at the top right of the screen, do you have a Site Information button?
If you have one and you click on it, what are the privacy settings specified?
@spidersbite, I updated the 1.0.9 with the fix for private groups. I also added a fix to make sure that the current web does not get selected by default when there was no web specified and the selected site collection wasn't the current site collection, that way it doesn't show lists from the current web randomly.
Please do the following steps and tell me if you still have the problem :
Sorry to trouble you, but I'm having a problem with the app deletion. I deleted the app from the app catalog and the recycle bin for the app catalog just fine. I deleted the app from the site and the recycle bin of the site where it was installed. Before that, I deleted the web part from the site page where I had it. Now I want to install the app on the site again, but I get an error saying there's already an app with the same version on the site. I'm trying to look up advice. I honestly haven't left a trace of it on the site unless there's something I'm missing?
@spidersbite no worries it’s a simple problem, this message is because you still have the previously deleted webpart in the second level of the recycle bin.
Once you delete something out of the recycle bin, it goes in the second level recycle bin, you can access this second level by clicking the link at the bottom :)
Once it will be deleted from the second level you will be able to add the new one.
Oh, that's good to know. Ok, I've deleted it from the second recycle bin and it let me install the app. I've tried to add it to my page and I get this error:
Something went wrong If the problem persists, contact the site administrator and give them the information in Technical Details. Technical Details [SPLoaderError.loadComponentError]: Failed to load component "ac515af1-4490-4c7b-8191-d49b41b26c5e" (ContentQueryWebPart). Original error: Failed to load entry point from component "ac515af1-4490-4c7b-8191-d49b41b26c5e" (ContentQueryWebPart). Original error: Error loading https://component-id.invalid/ac515af1-4490-4c7b-8191-d49b41b26c5e_1.0.9 Unable to load script https://publiccdn.sharepointonline.com/spptechnologies.sharepoint.com/110700492eeea162ee5bad0f35b1f0061ded8bf436ce0199efe2a4d24109e1c0df1ec594/react-content-query-1.0.9/content-query-web-part.bundle_2d94997ee5045f9247e12f500c038e56.js
INNERERROR: Failed to load entry point from component "ac515af1-4490-4c7b-8191-d49b41b26c5e" (ContentQueryWebPart). Original error: Error loading https://component-id.invalid/ac515af1-4490-4c7b-8191-d49b41b26c5e_1.0.9 Unable to load script https://publiccdn.sharepointonline.com/spptechnologies.sharepoint.com/110700492eeea162ee5bad0f35b1f0061ded8bf436ce0199efe2a4d24109e1c0df1ec594/react-content-query-1.0.9/content-query-web-part.bundle_2d94997ee5045f9247e12f500c038e56.js ***CALLSTACK: Error at t._generateErrorStackForIE (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:308:15958) at t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:308:15494) at t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:707:37339) at e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:707:43230) at e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:707:39667) at Anonymous function (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-16.021/sp-pages-assembly_en-us_bbf1ba8e18797f770e10fb0068654369.js:707:11278) at I (https://res.delve.office.com/lpc/versionless/livepersonacard_full_cb44cfdfef29798d503a.js:44:2084) at x (https://res.delve.office.com/lpc/versionless/livepersonacard_full_cb44cfdfef29798d503a.js:44:2200) at P (https://res.delve.office.com/lpc/versionless/livepersonacard_full_cb44cfdfef29798d503a.js:44:2023) at b (https://res.delve.office.com/lpc/versionless/livepersonacard_full_cb44cfdfef29798d503a.js:44:1611)
Yeah your browser still has the old code cached. Delete the webpart from the page, clear your cookies, refresh the page (Ctrl + R) and try adding back the webpart to the page
I had cleared all my browsing data previously. And I've done it again in IE and then tried the same in Chrome. I'm still getting the Something Went Wrong message.
@spidersbite, shame on me, I am the one who had the old code cached thus the reason I didn't have this error haha...The .sppkg I uploaded missed something, I just fixed it and added it to my dev branch again as well as in the pull request.
Go redownload the .sppkg to this link again and redo the steps, now it will work sorry again.
You should now see the comment "Previously committed wrong .sppkg" nex to the .sppkg.
Repeat all the steps (don't forget to clear cache again) and let me know 👍
@spidersbite you had a chance to test the latest .sppkg above and see if it fix your problem?
I just had a chance to do this again now. I deleted the app everywhere, cleared my browser cache, and added it again. I am still having the same problem. As soon as I choose my other site, I see the Select source web... in the second dropdown and I'm not allowed to go any further. The list dropdown below is grey.
Ok, at this point I guess I would need to debug with you using remote desktop because I can’t replicate this anymore.
Is the problem on your personnal tenant or on the tenant of ra business you are working for? Let me know if you could be available for debugging, it shouldn’t too long.
I appreciate the offer and I'd like to take you up on it. This is the tenant of a business I work for, so I need to double check with someone about security policies. When I get the all clear I can arrange a time to skype.
Aright, meanwhile, I feel like this is the first question I should of ask, but are the problematics sites enabled to be crawled by the search? If you go in Site Settings / Search and offline availability, is the site allowed to get it’s content crawled by the search?
Yes, both sites are allowed to appear in search results.
This is fascinating lol, if that can help you debug on your side, this is the exact search query I am doing in order to find the webs for the selected site collection :
_SiteName:https://yourSelectedSiteCollection.com AND (contentclass:STS_Site OR contentclass:STSWeb)
It basically looks for any STS_Web or STS_Site that has the property SiteName equal to the selected site collection. The reason why I included STS_Site is just because the root web is considered a STS_Site and not a STS_Web.
I suspect the problematic webs might NOT be STS_Web or STS_Site, what kind of template do the sites use? Are they normal team sites or something different like a blog site or something like that? Try the query in a search center without the AND (contentclass:... part and see if it returns you more results
@spidersbite, do you know the type of the problematic sites you are selecting? Are they standard team sites, group sites, blog sites etc? If you can tell me the exact template they use it would be usefull.
They were created as standard team sites.
And if you put the following query in a search center, do you have any results?
SiteName:https://replaceThisWithYourSelectedSiteCollection
ps : The SiteName property must remain as is, just replace the site collection url
That's interesting. There are no results.
Ok so we have the finger on it, normally the root web and all the other subwebs of a site collection should have their property SiteName set to their respective parent site collection url.
For some reason those problematic site collection don’t. My first thought would be that the root web is configured to NOT appear in search results, but it doesn’t look like it’s the case.
Are you able to search for documents located in the root web from the search center?
I'm going to take this conversation to email. I'll use the email on your profile.
Fixed this issue by using the managed property « SPSiteUrl » instead of « SiteName » in the search query which retreives the webs of a particular site collection.
@spplante I changed the search schema on my site collection today and now I can't get the web urls for the site collection to show up. Appears to be same issue as this. Tried some things to no avail.
Also, I changed the search schema back and it's been quite a few hours so not sure if related to crawl index or not.
Any help greatly appreciated.
PS. was working great until I changed search schema to hit the site collection on the root page instead of just the root site.
@spplante I've ended up hard coding the sub site...
/***
- Initializes the WebPart ***/ protected onInit(): Promise
{ return new Promise ((resolve, reject) => { this.ContentQueryService = new ContentQueryService(this.context, this.context.spHttpClient); this.properties.webUrl = this.properties.siteUrl || this.properties.webUrl ? this.properties.webUrl : '/resources/reference';//this.context.pageContext.web.absoluteUrl.toLocaleLowerCase().trim(); this.properties.siteUrl = this.properties.siteUrl ? this.properties.siteUrl : this.context.pageContext.site.absoluteUrl.toLowerCase().trim(); resolve(); }); }
This is not ideal but will hopefully get me through until proper fix.
Also, I've done some testing and this is definitely an issue with the search settings in SPO and/or the crawl frequency. Something happened after I changed the search settings, I'm certain of that.
Cheers
Garry
@spplante disregard last message as it didn't work in production. Worked in workbench though.
The only place this webpart uses the search is for fetching sites and webs URLs, it uses the getSitesStartingWith and getWebsFromSite methods from the SearchService.ts file which uses the SPSiteUrl managed property.
If you changed the out-of-the-box SPSiteUrl managed property make sure to put it back as it was, otherwise it might simply means that your site is not indexed, make sure to check that your site hasn’t been configured to NOT appear in the search, same thing for the web.
@spplante All I did was change where the search queries were being sent to...
Didn't touch the managed properties so SPSiteUrl is all good.
I've tested on a test site and it picks up the sub sites no problems. Only this site collection is having issues.
Do you think I could hard code the site somewhere? I'm working through it but I'm still learning TypeScript so it's taking some time.:)
@spplante All the sub sites are indexed and were showing up no problem before I changed that setting.
@spplante Worked it out and nothing to do with your code...
Someone (who shall remain anonymous) changed the search result sources for the site collection to 'Local People Results' instead of 'Local SharePoint Results'...and when I find out who did it...well...let's just say I'm gonna give myself a real good talkin too.:)
Thanks for all your help.
I've downloaded this version https://github.com/SharePoint/sp-dev-fx-webparts/tree/master/samples/react-content-query-webpart/sharepoint/solution. In my app catalog it shows up as 1.0.8.0.
I'm having this problem:
I was wondering if this was updated in a new version because I see references to updates but I just can't find the updated download. If this isn't a version issue, is there anything I can do to get the web part to pull the lists for the site I've selected?