I am using 'one state workflow' for image types in Plone, and it appears an anonymous user can still see an image even if it's 'publishing date' is set in the future...
Is 'publishing date' ignored in 'one state workflow' for images?
It also appears 'expiry date' is also ignored ie it appears when you dial up its url.
Note: I am accessing the image direct via it's URL eg my.site.com/assets/images/myexpiredimage
Perhaps these publish/expiry dates only useful for listings and collections etc, they dont control access and visibility?
Tried to find good Plone doco on this but couldn't... happy for a link to where this is explained?
Setting the publication- or expiration-date merely means the item will not show up in listings (navi-elements, search results, folder-listings), and is not to be confused with workflow-states.
A better solution would be to change the wf-state, when a date is met via a cron, which can be done quite comfortably with collective.contentrules.comingsoon.
Yet you need to rip out the default-behaviour of the concerned templates, I'm not sure, but maybe there is a proposal ("PLIP") already going on for this, if you find one, please leave the link here.
Refs: Control access on future content and How to retract content after expiration date
Yes, these things do nothing about people who have the URL, ever, regardless of workflow. The best quote for this I could find in three minutes is hidden in the user manual glossary.
Related
I need to modify the body of an existing GitHub issue in a Project. All I'll be passed is the title of the issue, and a word (the word exists in the body, and I'll just need to fill the checkbox next it).
It looks like to do this I'll need to use the GET API to get the body of the issue, modify it, and then use the EDIT API to swap in the new body. However the GET API can only be called with the issue number. I need to do all this as quickly as possible. Is there some way to search via an API call?
Thoughts much appreciated!
Edit: All my issues are in the same project (and issue titles will be unique there). I've also recently discovered Github's GraphQL API, which may be applicable here.
You can use the issue search endpoint with the in and repo¹ keywords:
GET /search/issues?q=text+to+search+in:title+repo:some/repo
Of course, issue titles aren't guaranteed to be unique. You'll have to request each of the issues that comes back and see if its body contains the word you're looking for. Even in that case you could get multiple positive results.
It would be much better if you could search by issue number.
¹I've assumed that you really mean "repository" when you say "project". But if you're actually talking about GitHub Project Boards you can use the project keyword as well or instead.
I'm attempting what I thought would be simple but has turned complicated. Basically, I have two websites in one installation. I need to retrieve the current quote (guest or logged-in) from the opposite website.
The sessions are shared across both. Here's what I've tried so far:
Setting the current store to the opposite store briefly, grabbing cart and setting it back. This actually does work for wishlists but not quotes
Setting the opposite store in core/session and retrieving quote
Parsing core/session visitor data for ID I could use to do SQL query. There is a visitor_id but have not found the link between that and quote
Has anyone done this before? Seems like there should be a way to grab quote using sessionId with storeId but I haven't found it.
Thanks!
Argh, was looking in the wrong session namespace. Should have been checkout/session (obviously) instead of core/session. Will go ahead and answer it, in case someone else has same obstacle.
$ecommerce = Mage::getModel('core/store')->load('ecommerce_store_view');
$quoteId = Mage::getSingleton('checkout/session')->getData('quote_id_' . $ecommerce->getWebsiteId());
I need two paginations on one page, is it possible to do this with codeigniter?!? Of course they must operate independently of one another.
Yes and no. If you want two different pagination visuals (customized renderings of the library) then sure. The problem you'll run into is by default the pagination library will pull the current page out of your $ci->uri->segments() list automatically to determine which page to mark as "active".
I do not know of a way to explicitly override this. Perhaps if you made a MY_Pagination that took an additional $config value for current page you could get it to behave like that. I haven't looked at the library's code in a while so you'd have to do some digging.
Honestly though, I'd suggest you build your own, it's not incredibly hard to do some simple math to determine what numbers to link.
Also you'll run into issues with CI's Pagination Library if you want the "current page" part to be NOT the last segment in your url. This may have been fixed lately but last time I looked it was the stop-gap for me using the library all together.
Bottom Line Invest the time in making your own if you want more than it's basic functionality, it's simple enough, just make yours reusable if you can.
New OScommerce user.
I've been fiddling around with Chemo's Ultimate SEO add-on the last few days. I've mostly got it working (minus one bizarre redirect loop for category pages?) but I'm a little disappointed in the limited options for formatting URLs.
I'm seeing:
http://www.website.com/category-awesomeproduct-p-1735.html
When we'd really like to do something more in line with:
http://www.website.com/category/awesomeproduct
What are my options? Am I out of luck?
I fear that the stock URL parameters are rigidly defined and that there's no way to hide the less friendly ones.
After researching this for quite awhile, and receiving no answers here, I believe the answer is: no
The view controller expects that data and it can't be omitted, even with customizations installed.
What do you think.. are clean URLs a backend or frontend 'discipline'
The answer is BOTH.
For example:
https://stackoverflow.com/questions/203278/are-clean-urls-a-backend-or-a-frontend-thing
The number above is a database id, a back-end thing. Chop off the pretty part and it goes to the same page. Therefore the "are-clean-urls-a-backend-or-a-frontend-thing" is part of the front-end thing.
If we're talking url's being 'clean' from an end user experience then I'm going to break the mould a bit and say that url's in general are not intuitive and they never will be, they are intended to be machine readable.
There is no standard to the format of a url such that when navigating from site to site humans will never ever remember how to reach a resource purely through remembering urls and their 'friendly syntax'. We can argue the toss about whether using a '?' and '&' or '/' to express how how to identify a resource via a url; is one method better than the other? it doesn't matter. At the end of the day a machine parses it and sends back the result.
We should stop deluding ourselves that people actually type these things in and realise that uri's are for machines, not people.
I have yet to use/remember a uri that goes beyond the first few characters of the http://domain.com/ part of an address, and I've been using the web since a long time. That's what bookmarks are for. Nowhere on a website does it say 'change this part here in our url to view 'whatever else' resource' because url's are usually undocumented and opaque.
Yes make your uri's SEO friendly (hell even they change periodically) but forget about the whole 'human/clean' resource identifier thing, it's a mystical pipe dream.
I agree with Vlion that url's should provide a unique mechanism to bookmark a resource and return to it (unlike some of these abominable web 2.0 ajax/silverlight/flash creations), but the bookmark will never be for humans to comprehend and understand. There seems to be quite a lot of preoccupation and energy spent in dreaming up url strategies that humans can remember and type in, it's a waste of energy. Let's get on and solve real problems.
Sorry for the rant, but there's a lot of web 2.0 nonsense related to urls going on in certain circles that are just a total waste of time.
Now that Firefox's Awesome bar and Google Chrome's Omnibox address bars can be used to search the browsing history it makes it much easier for users to search their history for previously visited sites, so having clean urls may help the user find sites in their history more easily.
Making sure the page has an appropriate Title is important (as both browsers search the title as well as the url) but by making sure the url has relevant keywords in it as well, when those keywords are typed in the address bar the urls will be more likely to show up higher in the suggestions as the keyword will be matched twice, in the url and the title.
Also, once a user has typed the name of a site they will be presented with example urls from the site which they can then use as a template for narrowing down their search. So using verbs and nouns in the url for different sections or actions of the site will aid the user to narrow their search to just the part of the site they are interested in, e.g. the /questions/ or /tag/ sections of stackoverflow, or the "/doc" at the end of docs.google.com/doc that can be used to view just document pages on Google docs*.
Since both Firefox and Chrome search for each space separated word typed into the address bar, it could be argued that it isn't necessary for searching that the url be completely human readable, but to allow the user to actually read the keywords they are interested in from the url the amount of "noise" should be kept to a minimum.
* which are of the form http://docs.google.com/Doc?id=gibberish
My perspective is simple:
every place I visit with my browser(with various edge case exceptions) should be bookmarkable and Forward/Back should be usable and not destroy any data entry.
Backend for sure. Your server is the one that has to take care of the routing to the resources requested by the URL.
I think the main reasons for using friendly URLs are:
Ease of linking / sharing
Presentation
Seo
So I think it's purely a client-side pleasure. While they're nice on the server as well, they're not mission critical.