This is more of a conceptual question, but it has actual ramifications.
Going through the various SEO plugins I found nowhere a PHP tag that should be embedded in the actual HTML page and echo the meta data. How does it work then?
Simply saving it to the DB doesn't seem enough. What is the mechanism through which the plugin "injects" the SEO data to the page? and what if I have my own meta tag in the page - Would it override the plugin?
The mechanisms are usually FILTERS and ACTIONS hooks from the wordpress Plugin API
This is not particular to the SEO plugins, but to almost all the plugins that change actual content .
simply put :
Action Hooks
Actions Hooks are designs to be used when WordPress core itself, some plugin or theme is giving you a special "breakpoint" to insert your code in order to do some action, or change something while a certain action is triggered .
Filter Hooks :
Filter Hooks are very similar to Action Hooks but what they do is to receive a value and potentially return a modified version of that value.
UPDATE I
see this simple example (put in your theme´s function.php
add_filter( 'the_content', 'my_the_content_filter' );
function my_the_content_filter(){
echo ':::::: THIS CONTENT WILL BE ADDED TO ANY POST :::::';
}
or this :
add_filter( 'the_title', 'my_the_title_filter' );
function my_the_title_filter(){
echo ':::::: THIS CONTENT WILL BE ADDED TO ANY TITLE :::::';
}
UPDATE II
IF however, your question is actually about how SEO works, and not the plugin itself :
SEO is a big subject, but simply put , it is about the meta-tags, titles, descriptions, links, rels etc ... this is what the SEO plugins are changing .
They change things like -
adding automatic descriptions and titles to images
changing page titles
adding meta tags by post
etc etc...
.. - but they all use the above mentioned mechanism of actions and filters hooks. the fact that you do not see it in the code, is that you do not know what to look for .
Try to save the page source BEFORE and AFTER the plugin activation, and then do a diff on both. You will see the differences ...
Related
This question already has answers here:
Mount react-admin under /admin
(4 answers)
Closed last year.
I am trying to integrate react-admin into an existing react app and am able to get the basic starter pages up and running , however, after adding a dummy resource and clicking on it in the UI, I am redirected to http://my-application.net/[resource name], which is incorrectly showing my applications error page.
I am trying to set up react admin in a sandbox-like scenario to avoid conflicts with some custom stuff I'm using for routing* and I currently have things set up to display react-admin under the /admin path in my app. Is it possible to tell react-admin to prefix all of its links (i.e. when clicking on a resource) with admin so that my app can correctly detect and route these pages to react-admin? For example, in the scenario from the last paragraph, when clicking on the dummy resource, i want it to direct me to http://my-application.net/admin/[resource name] instead of http://my-application.net/[resource name]
The closest I have been able to get is this SO post, which talks about adding admin/ as a prefix to the name of all resources. I have been able to make this work with some tweaks to my routing configuration to send all /admin pages to react-admin, but changing the resource names like this also has the side effect of changing them in the UI (i.e. my users resource appears as admin/users in the sidebar of react-admin)
Other things I looked at that didn't seem to be useful:
Using the customRoutes prop in <Admin>
<Resource>'s props seem to be intended more for tweaking the end of urls for different CRUD operations
this SO post seems like it might be about something different since this is the first mention ive seen of UrlField.
Does React-admin have an option to automatically add a baseUrl to all it's links?
* While not relevant for this question, the reason I am trying to do things this way is because my routing system (UniversalRouter, see here) is redux-based and appears to directly conflict with some of the redux state that react-admin needs according to the Using redux in a custom app tutorial.
An answer I found from a post the StackOverflow "related" sidebar seems to suggest that the history API has this kind of functionality:
The only other thing I can think of is properly configuring baseName in your history.
referring to this line in the OP's question (variable name changed for clarity):
const newHistory = createHistory({ basename: '/myadmin' });
Passing this modified history into react-admin's Admin component seems to achieve the intended behavior where clicking on resource links now correctly redirects to that resource underneath the specified baseURL.
<Admin ... history={newHistory} ...>
This is also mentioned in this other answer, which is way more concise than mine or the one i based this answer off of.
I'm trying to make an Ajax-call to my Controller.
I placed a hidden link in my form like this:
<f:link.action action="ajaxCheckEmailExistsFE" controller="Profiles" class="hidden" id="checkEmailExistsAjaxLink"></f:link.action>
In my Javascript, I extract the href from this link:
var target = $('#checkEmailExistsAjaxLink').attr('href');
And then send my request with jQuery's $.post method.
When the link is called, I get the infamous error
The action \"ajaxCheckEmailExistsFE\" (controller \"Profiles\") is not allowed by this plugin. Please check TYPO3\\CMS\\Extbase\\Utility\\ExtensionUtility::configurePlugin() in your ext_localconf.php
But the action is clearly set in ext_localconf.php!
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
'MyVendor.MyExt',
'MyPlugin',
[
'Profiles' => 'editFE, showFE, updateFE, ajaxCheckEmailExistsFE'
],
// non-cacheable actions
[
'Profiles' => 'editFE, showFE, updateFE, ajaxCheckEmailExistsFE'
]
);
The same workflow works perfectly in BE-Mode.
I had the same problem with the updateFE-Action. When the form was submitted, I got the same error like above. I had to add it to the switchable-controller-actions in my flexform (-> <numIndex index="1">Profiles->editFE;Profiles->updateFE</numIndex>) - which is equally odd.
Why is this happening???
This is TYPO3 9.5
[Edit] For the time being, I ended up adding the action to the switchable-controller-actions just like I did for the updateFE-Action.
This is VERY cumbersome, though, since I have to set the plugin-action on the page every time I add a new action.
If anybody has a better solution, I'd be extremely thankful!
Indeed, this IS cumbersome, but it is also the only working way for switchable actions in TYPO3 extbase controllers. This check is intended to ensure that specific actions are only callable when you are in the "correct" plugin, as you may have several plugins inside one extension, which then may utilize different actions. So in the end, this feature prevents one plugin to call an action which should only be callable inside another plugin of the same extension.
If you do not need the editor to switch action sets of your plugins though, you can remove this config part from your flexform, which will solve the need to edit this for new actions.
As a famous example, take a look into the config of the news extension. There is one plugin which allows list+detail view, and different ones for just list or just detail view. So as an admin, you have to choice of structuring your website (routing and templates) for different news setups.
Even in the TYPO3 community, there are voices to get rid of this feature, so maybe it will be solved in future versions.
Wondering the best way to prevent a GTM tag from firing. I found https://rbardini.com/automating-gtm-data-layer-tests/ which tags about fetching the dataLayer variable and comparing it in an assertion, but this looks like a clumsy approach when you want to write to the dataLayer on every page.
For example, it suggests:
const getDataLayer = ClientFunction(() => window.dataLayer)
We use Google Tag Manager to automatically load tags on our website. Unfortunately one of them is CloudIQ (from PayPal) which pops up an iframe overlay offering a newsletter signup or ability to save your shopping basket. The Trigger in our GTM setup for that tag is simply 'All Pages'. When it pops up it generally blocks our test because Selectors cannot be clicked.
Our page flow is over several pages of an online shop, e.g.:
visit home page, click a product - navigates to a product page
click some options on the product page, then add to cart
go through checkout flow
So there might be many pages visited due to click actions.
There is an ability in GTM to define Variables and then use them in Exceptions for a tag, so I could prevent the CloudIQ tag firing either via a/ a global variable or b/ a dataLayer variable. However, I can't see how to elegantly get these set for each page visited during my test, such that they would exist when the GTM examines variables in order to block a Tag from being loaded. Fixture.beforeEach isn't right because it would only run once per fixture, and any data it set on the page's scope would be lost as soon as a page navigation occurs.
Anyone got experience of this sort of thing?
(The alternative of course is to detect the overlay, use switchToIframe to switch into the CloudIQ iframe and close it manually, but it pops up quite erratically and I'd prefer to simply disable the Tag altogether during tests as it's not core functionality of our website that we need to test.)
One way would be to set a custom user agent string to your test suite, create a custom javascript variable that returns the value for navigator.useragent, and make an exception trigger that blocks the tag.
Or any variation on that theme - set a cookie, use a url parameter, or if you test suite allow inject a global js variable, and check for the value in an exception trigger.
There is no need to avoid firing of events on the client side. Just mock the service routes for Google Tag Manager and CloudIQ and imitate correct responses for them.
I have a bigger webpage and it would take days to add the loading=lazy attribute to all img tags on my site. Is it useful to use something like $('img'). attr('loading', 'lazy') (does this work?) to the site, or will it just make the site more slower?
It doesn‘t necessarly have the expected effect - if you‘re adding the attributes via JavaScript, the page itself has already been parsed by the browser and their preloading scripts as well and all of those images would be been put to the download queue, as if the attribute wouldn‘t have existed on them.
So I would heavily recommend to add those attributes within the source code itself already.
Inherited a Sitefinity website. There's a news list page, which I discovered is reused by the news detail pages to display content. If I update the list page, the changes are reflected on the detail pages.
Sometimes.
I have a content block that contains a "header" text - updating this in the list page is replicated across the details pages. Adding a javascript widget to the page to inject some custom javascript replicates across the details pages as well.
Adding a new content block or css widget does not replicate across the details pages.
Is there some rhyme or reason to this behavior that I'm missing?
My specifics:
I've successfully created widgets in the MVC several times now. I essentially need to add a new widget to just the news pages. Which seemed simple enough until I discovered that news pages are not individually created pages like... well, pages... but instead are just a content piece that is dynamically inserted in the news widget on the "parent" listing page. At least as far as I can tell that's how it appears to be working.
Adding my widget to the page didn't work, as I explained above. I then tried recreating it in the page itself using javascript, content block, and css widgets, at which time I discovered that the javascript is the only one making it to the details pages. I imagine this has to do with the way javascript widgets actually make it to the page - their placement is selected in advanced options, rather than simply appearing inline.
Sitefinity widgets go beyond presentation, and actually control routing.
As such content widgets (baseline or custom) have two 'modes' that they operate in: list and detail. Slugs for details are automatically generated in the following format.
/News
/News/{News-item-slug}
Of course, a list and a detail should look very different. To accommodate that, the widgets have two separate configurable templates.
So, add your custom html and javascript to the appropriate template to have it only apply in a given mode.