I'm testing Laravel Cashier for accepting Stripe payments. Everything is working, but still looks bad. I see in the docs that there is a 'cashier.payments' page that can be published so we can modify it to match our page. I'd love to use that, but I can't see how to use it. There's no existing route and without the code, I wouldn't know how to create one (it requires some parameters).
I tried php artisan vendor:publish --tag="cashier-payment" (based on the instructions for publishing the billing-portal), but the response was 'No publishable resources for tag'.
I've looked through the 'vendor/stripe' folder, but can't see anything like 'cashier/payments' that would help.
Has it been removed? Or does anyone know how to activate it?
Related
I have undertaking a master thesis project that uses the openapi.yaml files to auto generate test for REST-api web-services - This has lead me to host a local instance of gitlab, so that I can run the tool I am working on, on gitlab. For that to happen I need the .yaml files containing the documentation for the API calls. Such files are found within in the gitlab source-code, but the call does not seem to work.
Some calls work, namely:
http://localhost/api/v4/version
http://localhost/api/v4/users
http://localhost/api/v4/projects
http://localhost/api/v4/groups
all returns meaningful JSON.
the problem is that a lot of the calls within the documentation does not work (returns a "404 not found"), namely:
http://localhost/api/v4/metadata
http://localhost/api/v4/projects/{id}/access_tokens
and more calls specified in the documentation.
The problem is that a lot of the calls that work are not documented (all of the above except the 'version' call). I have really tried to look for an alternative openapi.yaml files, but with little success and I am also puzzled to why the one left in the actual source-code does not contain meaningful documentation. Have I overlooked something? I am currently using postman and providing a sudo authentication-token.
Thanks in advance - I must surely have overlooked something!
Currently I have tried to look for an alternative openapi.yaml both by googling and be browsing swaggerhub.com. I Have look at the documentation pages for gitlab, but I have not found anything I did not already have.
Unfortunately, at this time of writing, GitLab does not provide an OpenAPI spec for all of its API. Only a very small part of the API is documented in openapi.yml. There is an open issue that is tracking this improvement.
For now, the online API docs are going to be your best source of information available on using the GitLab API.
As for your problem of getting 404 responses, the most common cause of this is that the credentials you are using do not have permissions to the project/feature you are trying to access or you are not using a proper authentication method. Also keep in mind some features of the API require an appropriate license entitlement.
I run my blog that linked with Cloudflare when I create a new post I don't see the current post that affected my site. I tried many methods that I learned from sites like trying to use a page rule to bypass Cloudflare cache but it didn't work. Also, I turn it off auto minify js, CSS, and Html still does not work. my blog still shows the oldest post that is from since 5 days ago. When you log in WordPress dashboard panel you will see the current posts but for the normal visit will see the cached posts that remain static all time
here is my Cloudflare setting
Page Rules Settings
Page Speed Settings
Page Caching Settings
I need your help from everybody who knows about this problem and how we can solve it
Thanks....!
Looking at the site now, looks like you have maybe disabled Cloudflare? I'm seeing the latest posts, and there are no Cloudflare response headers coming back.
For troubleshooting caching issues, one of the most useful things you can do is to inspect the response headers (using Chrome Dev Tools or similar 'Network' tab). First step is to identify which request is responsible for the cached content (a document, or an AJAX call, etc.)
From there, you can look at the response headers to see why it is behaving this way, specifically you'll want to check the Cache-Control and CF-Cache-Status header. More info here - https://developers.cloudflare.com/cache/about/default-cache-behavior
I fixed this problem because all performance is managed by Ezoic. I tried to purge everything on Ezoic and all things are working perfectly.
Following a migration, I am trying to reconfigure TYPO3.
The backend is accessible by its url and I manage to connect. But the home page for example gives me the following error: The page did not exist or was inaccessible. Reason: No site configuration found.
All pages are not accessible by their url normally but are accessible through different query parameters, like /index.php?id=2&L=0.
I already tried to replace the .htaccess with the basic one provided by TYPO3, I also checked the Apache configuration and everything seems to be ok. I am not familiar with the TYPO3 CMS so I don't know if some of these configurations are done directly in its files. To me, it seems to be a mod_rewrite problem but I can't find it.
Someone would have a solution or at least a track to solve this problem?
As stated in the error message that you've posted it seems that the site configuration is missing. In the TYPO3 backend you can create new site configuration via Site Management => Sites.
Please check the site handling documentation for details.
I'm a new to RESTful API's and sort of developing my first one at the moment for a mobile application to be followed. I have a question regarding API versions and how to manage/tackle them.
At this moment, my API 'version' is a directory named v<version_name> in which my API class resides. In that directory, I have resources that the API and REST client needs in another directory named include. So the structure is as follows: example.com/api/v0.2/method_name/ and on .htaccess, I'm making sure that everything that follows the API version (hardcoded in the .htaccess file, is saved in a query string parameter).
I'm not sure if it is the right approach for a live application as it requires manually changing the URL endpoints at clients' ends, too. So my questions are:
Is this the right approach to API versioning?
If it is and I keep it, how do I deal with outdated URL's. Say for instance the app is live and I update the API to v0.3 but the client who have the app installed would be accessing v0.2 and getting a 404 response code back?
Is there more elegant solution out there? It must be.
Edit: there are some resources that reside outside of the api folder itself, in the root include folder so to speak.
Edit 2: My API is targeted to be consumed by mobile applications and is not publicly consumable.
While I think these questions are primarily opinion-based, I will have a go...
I think it is a valid approach, and I've seen others use it,
including Microsoft.
When it is necessary to outdate an API, you could give a 404
back with an explanation that the new API is at the new address.
HOWEVER it is usually a bad idea to just retire an API version; you
would at least have to give client developers enough time to switch
to the new API before retiring the old, if at all.
A more elegant solution would be to just keep the API at one
address, and update that as necessary, and add to it rather than
replace whenever possible. Keep supporting outdated functions for as
long as possible and have open communication to client developers
about when a certain method will no longer work.
Just my opinion, do with it what you will...
Hi I have created a package for my metro application.Here while developing my app I have given a Url static,But I need to change Url dynamically whenever my requirement changes.So that what should I do?Can anyone help me.
Thank you.
If your requirements are changing, then you might be releasing a new version of your application anyways, so it might make sense to just update your app package manually each time the URL changes and re-release it. This is definitely the simplest solution if your URL is going to change infrequently. You would also need to handle deprecating the old URL in this instance or at least gracefully handling when the old URL is shut down so that users who have not upgraded to your latest version still don't have a horrid experience.
If that is not a viable option, then it gets a bit messier from here on. Really the only way to change the stored URL would be to have some sort of secondary service or authority on what the current URL is. The app would then do one of the following (or a combination):
Query the URL authority for the current URL before making any requests.
Attempt to make the request to the current stored URL, if it fails, query the URL authority for the new URL and store that URL.