To start this is not an ACL issue.
I am having troubles adding and removing objects to some users this way:
PFUser.currentUser()!["Key"].addObject(object)
etc... and actually any other way present in Parse documentation.
To make the problem clearer, I have several users in Parse and I can modify only one column of this one user. The other columns, with all similar attributes, are not responding to my requests, even though I only change the key from the one that works. Furthermore, for this same column that works for one user, doesnt work for the other...
I am weirded out. Anyway, I was wondering if anyone has ever encountered such issue. I have conducted several hypotheses but none revealed correct.
Any help would be acclaimed and welcomed with wide open arms.
Thank you for your time.
Viktor
Try PFUser.currentUser()!.refresh() before trying to set or get values to see if it's not a cache issue.
Related
I'm using Swift on iOS and Firebase
I am trying to find a way to delete a post when it was shared more than X hours ago, no matter if the user is connected on the app, or not.
For that I have set a time stamp for my post object, which gives the date/time when the post is initially created.
I thought about adding a "timer" to my post node, that would be updated every second. The problem with that is that I would need for that to make a request to my database every second, and this would obviously be very data consuming.
I googled a lot and it seems like the only way of doing this is using some server-side code in Javascript using Google Functions, and I read the documentation but I still have no idea how I can do that and can't barely find anything refering to it.
Do you have an idea how to solve this problem?
Thanks!
Title says it all. I have a store (PrestaShop 1.6.0.11) with dozen of combinations, some attributes are compatible with other and some not.
I'd like to hide some attributes depending on the choice of another, which PrestaShop obviously does not as I'm still able to select attributes even if the combination of these attributes is not possible.
Instead it adds a nice warning :
This combination does not exist for this product. Please select
another combination.
You can imagine time to spend if 10 or more combinations are not possible...
I tried to find a solution on the web, even asking on PrestaShop forum, but seems I'm the only one having that issue.
Any idea ? Thanks in advance
Apologies in advance as I'm sure this topic has no doubt been asked before but I couldn't find any post that answers my specific query.
Bearing in mind that I'm new to MVC this is where I have got to. I've got a project developed under VS 2010 using the MVC 3 framework. I've got a search page which consists of 6 fields and a nested model which itself holds around 3 fields.
I can successfully post all this data back to itself and the data is successfully passed as a model and back agian so the fields keep the data which the user has supplied.
Before I move on to actually using this search criteria on another view a thought hit me. I want to keep this search criteria, and possibly even the search results in memory for the duration of the users session.
The reasoning behind this is simply to save my users time by:
a) negating the need to keep re-inputting their search criteria regardless of how they enter or leave the search page
b) speed up the user experience by presenting the search results more quickly
The later isn't as important as the first requirement.
I've done some google searches and indeed had a look through this site on similar topics. From what I've read using sessions (which I would typically use if developing a PHP site) is a no no. From the reasons I've read as to why you shouldn't use sessions seem valid and I'm happy to go along with it.
But now I'm left in a place where I'm scratching my head wondering to myself what exactly is best practice to achieve this simple goal that could be applied to similar situations later down the line in the project.
I also looked at the OutputCache method and that didn't behave as I expected it to. In a test I set the timeout for 30 seconds. After submitting a search I clicked the link to my search page to see if the fields would auto-populate, they didn't. But then clicking the search button the values in the cache were retrieved. I thought I was making progress but when I tried to submit a new value the old value from the cache came back i.e. I couldn't actually change my search criteria with the cache enforced. So I've discounted this as an avenue to explore.
The last option seems to suggest the use of cookies as the most likely candidate, but rightly or wrongly I feel this isn't the best solution. I would have thought the MVC 3 design pattern would have an easier and recommended method of persisting values. I'm sure there is but I've just not discovered it yet.
I have started to use JQuery and again this has been mentioned but I'm not sure this is right direction to take either.
So in summary my question really comes down to what is considered by the wider community as best practice for persisting data in my situation. Effiency, scalability and resiliancy is paramount as I'll have a large global user base that will end up using this web app.
Thanks in advance!
Pete
I'd just use cookies. They're simple to use, you can persist them for as long as you want or have them expire when the users closes their browser, and it doesn't sound like you are storing anything sensitive in them.
I have an issue with passbook when trying to open a Pass's passURL as follows:
PKPass *pass = .....
[[UIApplication sharedApplication] openURL:[pass passURL]];
Now this works fine in most cases, but when there are many passes in my passbook, sometimes my passes get grouped like so, and have to be swiped through:
The issue here is that when the passes become grouped in this way, the bit of code I supplied above just opens the group with ANY of the passes in the group on top, not necessarily the one that was supplied in the passURL.
Now here are the things I tested and now know:
the passes have DIFFERENT pass URL's
the passes are grouped based on a bunch of criteria; I've had passes from the same organization not be grouped, but sometimes be grouped. Same with styles (coupon, event ticket, etc.)
I looked through Apple's dev forums but saw no mention of this bug (if it indeed is a bug and not my error). I was wondering if anyone else saw it and whether they found some workaround or could reveal my mistake.
Thanks,
EDIT:
All our passes use the exact same pass-type-identifier.
Thanks John. I am facing exactly the same issue. The issue still exists in iOS 6.1.
I also ran some tests, and the grouping logic seems be the following.
Passes from different pass type IDs are never grouped.
Passes with different styles (coupon, boarding pass etc) are never grouped.
Passes with the same pass style may be grouped. The grouping is based on similarity among the data fields, barcode types, maybe some other fields. But it seems the organizationName, description, logoText, foregroundColor and backgroundColor don't play a big role here.
Hope that helps.
Well, my question is simple.
Does the ID affect the position of a webpage on Google ?
I have links like this
http://example.com/news/title-slug/15/
and people say to me that I should remove the ID from the URL.
And I belive that is not true. By my logic, you can't depend on the title's slug. I know it should work perfectly fine if there aren't two pages that have the same title, but why should I remove the ID if there is no harm when it's there.
Yes, leave it there.
Google has no business trying to second-guess what each element of a URL represents and changing its index based on that.
URLs by their nature can map to any resource, and I'm pretty sure Google recognises that. All you should do is ensure that multiple URLs don't have the same content by using redirects. So, for example, http://example.com/news/wrong-title-slug/15/ should redirect back to http://example.com/news/title-slug/15/ rather than just echo back the same page. Google doesn't really like duplicate content.
It's fine.
But I would not put that behind the title-slug though. Some url might get more confusing than the others.
http://example.com/entry/how-to-solve-question-45/15
a better one would be :
http://example.com/entry/15/how-to-solve-question-45
Besides, you can't really rely on just the title-slug, because changing the title of an entry means breaking user's bookmark. Not to mention that it is faster to retrieve an entry from the database by an integer ID instead of an url-slug.
The problem here is not whether Google will accept it, but whether or not doing so is user-friendly.
A common reason for keeping the ID in a URL is to ensure that the URL is unique. For example, if two people on here were to create a question named "Jon Skeet Facts" we'd have a problem, whereas with the ID the users are aware that they are two different questions with the same title. This is the same as with relational databases where a unique identifier is required.
In essence, why care what Google thinks? The whole Search Engine Optimisation industry is a farce, and this is coming from someone who has been paid more than once as a SEO Consultant. Why follow what Google wants when you can map Google's intentions by making your website perfect for the user? If you make a good website Google will reward you. The ID has a reason to be there, so keep it in.
I think your fine leaving it in. Seems to make sense as you get the element for identification and the element for being descriptive. It is done on here after all.
Zeus won't strike you down for it. I prefer not to have meaningless numbers in there because it's not very attractive or semantic.
Having the id will NOT hurt your SEO rankings. Having the slug there ensures that the page's main keywords will be indexed so it's all good.