I want to debug in my custom extension backend module but f:debug not working in backend.
Also I have set 'debug' => true, for both backend and frontend in Localconfiguration.php file.
Please check your Application context. if it is Development then <f:debug> works.
<f:debug>foo</f:debug>
Should still work. Have a look at the bottom of your BE output.
Related
I faced a problem while creating static pages in Next JS with GraphQL requsts using fetch.
I've created page where I render over 100 list of data and also created static dynamic pages for those items using generateStaticParams function provided by Next.
Local build was done without any issues but when I deployed it to vercel, build crashed.
I am wondering if the problem is somewhere in WordPress.
To check it I replaced those static pages with https://jsonplaceholder.typicode.com/ - free fake API.
And with that API everything works fine.
Error that appeared during vbercel build:
I would be grateful if someone could help me with this.
Thanks :)
I tried different API to check if this error will also happen, but everything worked fine.
My operating system: Windows 11
Node version: 18.12
Next version: 13.1.6
The issue appears to be with using fetch in Server Components.
You can either use axios OR inside next.config.js set:
module.exports = {
experimental: {
enableUndici: true
}
}
I have developed my project using vue.js webpack template. I want to configure firebse cdn/caching. But have no idea what to do..
I have gone through the document https://firebase.google.com/docs/hosting/manage-cache
And found that
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
to be added. But wheredo i add in my vuejs project before deploying. Please if anyone could help me.
The method res.set sets the response’s HTTP header field to value. This link you have provided, refers to setting the headers when using Google Cloud Functions. You can take a look at this Github link containing an example about Google Cloud Functions which include how to set these headers in NodeJS. To get more general information about res.set() and how you can set these headers in your own application, you can also take a look at the official documentation.
Im trying to add some custom javascript to my admin but not having such a good time. What I tried so far is.
Requirements::javascript('../mysite/modules/widgets/widgets/calculator/admin/js/admin.js');
The path is correct because when I do fopen to that it returns true.
I have also tried the following.
LeftAndMain::require_javascript('../mysite/modules/widgets/widgets/calculator/admin/js/admin.js');
Same thing with fopen.
It doesn't give any error niether is it loaded(I checked network tab in dev tools)
The path should be relative to the site root not the cms or framework folders. In other words: 'mysite/modules/widgets/widgets/calculator/admin/js/admin.js'
Depending on your situation, I've had more luck using yml for this. I'm not convinced the dynamic loading always works perfectly on ajax requests. In this case it would look like:
LeftAndMain:
extra_requirements_javascript:
- mysite/modules/widgets/widgets/calculator/admin/js/admin.js
Coming from ZF background I was quite surprised to see Symfony's app_dev.php file. It seems like a very bad idea security-wise. It's one more step you need to take to make sure your dev is not accessible in production. I.e. you can't have simple Git deploy, unless you don't mind having dev version on production or have post checkout hook to remove the file or specific vhost setup that disables access to it.
What is the idea behind it? Why is it better than IP-triggered or ENV based dev mode?
First off all, there is no real "production" and "dev" modes per se. They are just named that way. You could easily use other modes, each with their own set of configurations which are loaded through config_<env>.yml for instance. Actually, there is a third standard mode called "test" which is reserved for testing Symfony.
Second, it's very easy to test things in "production" mode and "development" mode by simple add app_dev.php in between your url. This will make it easier to look at how your app actually looks like in production, without losing all the nice things like verbose logging and the web debug toolbar.
And as stated: by default the app_dev.php frontend uses by default a whitelist so even if you happen to push this file onto production, they would not be able to view it).
There are other reasons for multiple entry points: as an Symfony application can contain multiple applications at the same time. By default, app.php and app_dev.php are the front controllers for the default application, but it might be possible (quite easily actually) to have an admin.php and admin_dev.php as well, bootstrapping a whole different application, while still being part of the same repository (if this is a wise thing to do, is up for debate).
There is an issue #677 discussing why it's this way. There are also some interesting comments in related issue #11310.
The most reasonable argument for me is that it just works out of box without the need to setup environment variables or anything else. Although counterargument is that you still need to setup htaccess rewrite anyway.
if you look into app_dev.php file, you can see that only whitelisted IP addresses have access to app_dev.php file.
// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(#$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1')) || php_sapi_name() === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}
I am using node.js on my rackspace server to serve my various applications. (Using node-http-proxy).
However, i would like to start a wordpress blog. The only way to serve the blog is via apache (or nginx).
Is there a way to server my wordpress blog from a node.js application itself?
You need some server running to execute the PHP. Node is JavaScript.
Whether that's apache, or nginx/php-fpm or just php-fpm, you need something to actually run the wordpress code, then use the same proxying system you are using now.
One option is to continue to use Wordpress as you normally do, but instead of writing the templates to output HTML, you make them output JSON. With this minor trick, you suddenly have created your own API to output your wordpress content. In contrast with the modules that expose wordpress complete set of methods, this will create your very specific output, tailored after your needs.
To consume your JSON output, you set up a small nodejs server that forwards each call directly to your Wordpress solution, takes the response (JSON) and merges it with your html using whatever javascript template engine you like. You also gain speed, since you can cache the JSON result pretty easily on the node side, and control.
I've written a blogpost about this if you like to read more, and also created a nodejs express middleware to help setting up the node side.
http://www.1001.io/improve-wordpress-with-nodejs/
You can try express-php-fpm package.
It combines Express (Node.js server) and FastCGI gateway to serve php requests.
I found this node module while searching for Wordpress + Node:
https://github.com/scottgonzalez/node-wordpress
I haven't tried it, though, but if you know what you're doing you might want to give it a go.
I recently needed to get a server within an electron app to serve PHP.
I started with grunt-php by Sindre Sorhus. The main change I made was to remove the code that kills the server process when grunt is done, instead instantiating the PHP class from JS and calling the process as needed.
Ultimately, it was very easy to adapt grunt-php to enable PHP on a node.js server.
WordPress now has an "official" (to be precise: open source, under Automattic's github repo) way to do this: wpcom.js. From that github page:
Official JavaScript library for the WordPress.com REST API. Compatible with Node.js and web browsers.
The essence is to call the WordPress REST API from JS.