I want to query some information about articles or users from a Joomla website for my client-side application.
SOP can be ignored. I am working with Joomla 1.5.26 and I have an account with full rights. Unfortunately, I cannot access the source code at the moment.
For example:
http://example.com/index.php?option=com_content&Itemid=53
I would like something like this, but this returns full html page, not the article information.
And what if I would like to get many items at once sorted by some attribute like:
http://example.com/index.php?option=com_content&count=10&sortBy=latest&format=xml
Would like to see something like:
<articles>
<article>...<article>
<article>...<article>
<article>...<article>
</articles>
I haven't found a good explanation of the default query schemes.
Worst case scenario would be parsing the html, but I really hope there is some other way.
Any ideas?
Important: Joomla 1.5 and 2.5 are not longer maintained. Please upgrade to a stable and safe release.
But if you really insist, you can use "tmpl=component" as paremeter or just the index2.php to get the component content only (without template).
Everything else you will find under https://docs.joomla.org/How_to_override_the_output_from_the_Joomla!_core
Related
For the construction of an extensive list of links, since the source page is a thematic portal, I am looking for a suitable EXT., Which also runs under TYPO3 7.6 LTS.
it if the list of links to a permits the use of categories and multiple categorization of links is possible would be nice. should Weiterrhin the links are described not only the destination address and an alias but here should still an outline of the target page (possibly with photo) be possible.
Additional functions such as proposing links by users, reporting broken links or even a User Voting would nice additional features.
There were times the Modern Linklist, but they were no longer being developed for TYPO3 <6.x.
Is there perhaps somewhere an alternative or as one might like to vorhnandenen solutions might realize? It would be nice of course, without any programming knowledge, since I'm not a programmer.
P.S .: It is not about building a spam list but high quality links with topics relating to the original page.
As this seems to be a straight forward usage you could try to build that extension by yourself with the ExtensionBuilder.
just build up the records neccessary for your data. and let the EB generate all usefull actions: list & show, even create, edit, delete in FE would be possible.
Afterwards you just need to edit the generated fluid templates.
these links may help:
Overview
EB manual
small remark: if you want the newest code state, use the EB from git instead of TER
I`m not aware of an existing extension for it but it could be a good project to learn extbase / fluid.
You should also take a look at
typo3/sysext/fluid_styled_content/Resources/Private/Partials/Menu
and
typo3/sysext/fluid_styled_content/Classes/ViewHelpers/Menu
Fluid Content contains everything you need to create a list like that, you "just" have to combine the necessary bits and pieces.
You can do a lot with TYPO3 core functionality: there is a page type "external URL", pages can have categories by default, there are plenty of menu options (TypoScript HMENU, menu content elements, Fluid menu Viewhelpers). The Linkvalidator can periodically check all links and report broken links.
For suggestions you could add a form. Powermail for example can also store submitted info in database records, so your visitors could prepare page records (they are hidden until you make them visible).
I've got a small bit of code on my Shopify thank you page for a home grown fulfillment system. In oversimplified terms, it outputs a URL with template code that uses the {{id}} field.
<p>
Your order information is {{id}}! This is not the actual code,
this is just an oversimplified version for this question
</p>
Up until a few weeks ago, the {{id}} template variable would output the ID of the order object. I use this ID and the Shopify REST api to fetch order information. Now, for reasons that remain unclear to me, this outputs a different number that appears to be the checkout-id field.
Is this intended behavior? Is there anyway to get the old, real order object ID back? I can think of numerous ways to work around this, but I'd rather not mess with a system that's worked in a stable way for the past 5 years.
Documentation on this is spotty at best, but it seems like the old global liquid variables I've been using have changed their behavior. Acording to Shopify's documentation, on that Thank You page
You have access to the checkout and shop liquid objects
There's documentation on both the checkout and shop objects, and I was able to get the old behavior I was after by replacing {{id}} with {{checkout.order_id}}.
It also appears there's a liquid order object available as well, but given it's not documented as being available on the checkout page, I'm not sure I'd trust it to keep working.
we're just completing a new site build. With the current theme, we have had issues with structured data (we've highlighted it on Webmasters tools, and weeks later had to re-highlight it, and even then the highlighting prediction is not where we would like it to be).
It seems like Google is not able to find our Title, author, categories, content, featured image, date very easily. I'd expect to be able to communicate this to Google with 100% accuracy, since its so simple and we use the same format for all our articles). So maybe our theme is missing something by way of tags or something in the code to point to and identify this data?
Is that the case? Could someone please tell me what this aspect is called (so I can research it by its term), explain what I need to do with the new build, point me in the direction of an authoritative explanation/tutorial?
The site in question is a WordPress site, but I also am working on some php sites and would like to use this information on all sites, if it can be applied this way.
Thanks
You can use micro-data to mark-up the structured data. Also Google will really like your site if you show him (with a code) everything about the site - navigation, sidebar (aside), content (article) and so on. I suggest you to read about schema.org and micro-formats.
Here is an usefull article about your problem and how to implement micro-formats to your site.
I get the following errors from the Google Rich Snippet Tool for my website http://iancrowther.co.uk/
hcard
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
Warning: At least one field must be set for Hcard.
Warning: Missing required field "name (fn)".
Im experimenting with vcard and Schema.org and am wondering if I'm missing something or the validator is playing up. I have added vcard and Schema.org markup to the body which may be causing confusion. Also, I am making the assumption I can use both methods to markup my code.
Update:
I guess with the body tag, I'm just trying to let Google discover the elements which make up the schema object within the page. I'm not sure if this is a good / bad way to approach things? However it lets my markup be free of specific blocks of markup. I guess this is open to discussion but I like the idea of having a natural flow to the content that's decorated in the background. Do you think there is any negative impact? I'm undecided.
I am in favour of the Person structure, this was a good call as this is more representative of the current site content. I am a freelance developer and as such use this page as my Organisation landing page, so I guess I have to make a stronger decision of the sites goals and tailor the content accordingly, ie Organisation or Person.
I understand that there is no immediate rich snippet gains, but im a web guy so have a keen interest in these kind of things.
With schema testing, I find it easiest to start from the most obvious problem, and try to work our way deeper from there. Note, I have zero experience with hcard, but I don't believe the error you mentioned actually has anything to do with your hcard properties.
The most obvious problem I see, is that your body tag has an itemtype of schema.org\Organization. When you set an itemtype on a dom element, you are saying that everything inside of that element is going to help describe that itemtype. Since you've placed this on your body element, you are quite literally telling Google that your entire page is about an organization.
From the content of your page, I would recommend changing that itemtype to schema.org\Person. This would seem to be a more accurate description. Once you make that change and run the scanner again, you may see more errors relating to the schema and we can work through those too (for example, you'll probably need to set familname and givenName).
With all of that said, you should know that currently there are no rich snippets that you will gain from adding this schema data. Properly setting this up on your page, is only good to do, especially since we don't know what rich snippets Google or others will expose in the future, but currently you won't see any additional rich snippets in Google search results from adding these tags. I don't want to discourage you from setting this up properly but I just want to set your expectations.
I was wondering what is the best practice for creating forms in Wordpress? As a developer I hesitate to use a plugin like CForms, but I can understand why someone would like to use it. In the end I want to know the following:
What is the best practice for creating forms in Wordpress? (Custom HTML/CSS with Javascript and PHP validation or just using a specific aspect of the Wordpress API?)
I don't use any part of the WordPress API for forms. You could automatically grab the name and e-mail address out of the cookie WordPress creates when someone leaves a comment, if you want to try to auto-populate some fields.
An easy way to handle forms is to use Page Templates. That lets you create a new PHP file for a specific page, overriding the default page template of the theme. Then you can simply have the form post to itself and this one page template handles the processing as well.
http://codex.wordpress.org/Pages#Page_Templates
A lot of what's available for WordPress in the way of addins, and what gets a lot of attention, is stuff that I find makes little use if you have programming and general web skills. Almost always they seem to (necessarily) overgeneralize a requirement with a zillion options and configuration requirements because they are first of all designed for non- or barely-programmers.
Just learn the fundamental paradigms, scratch your head and wonder why nothing is consistently abstracted and/or encapsulated, get over it, and use what you already know about php and HTML-based forms. WordPress doesn't add much in the way of either tools or constraints.
I find the Widget feature applies usefully to most everything these days, and Forms is a candidate. But that's my own WordPress viewing prism - YMMV.
What do you mean by "in Wordpress"? Do you just mean placing the form HTML in a Wordpress template? Or storing data collected in the Wordpress DB? If you just want to create a form on your site, there's nothing Wordpress-specific to worry about. I believe there's some special Wordpress data facilities you can use if you're creating a widget or plugin or whatever they're called now. But if you're not, just create the HTML, and point it at a target URL that processes the values and puts them in a DB, Wordpress or otherwise. That target URL could be a separate PHP resource, or the same page. If it's the same page, you just need to include your PHP somewhere in the main Wordpress flow.